Re: Exporting functions

[Ori Bernstein <ori@xxxxxxxxxxxxxx>]

Oh, that should be pretty easy then. If the function is actually /named/ main, and is not part of a package,
the compiler exports it. (a bit of a hack, I guess, but easier for short programs). So, e.g.:

	const main = {
		...
	}

will end up getting exported. Otherwise, the 'pkg' mechanism does what you want:

	pkg foo =
		const main : (->void)
	;;
	const main = ...

the assembly name will be 'pkgname$funcname', in this case 'foo$main'.


On Jan 14, 2015, at 11:01 AM, Ryan Gonzalez <rymg19@xxxxxxxxx> wrote:

> Well...
> 
> I made a basic x64 kernel in Myrddin based on rustboot64 using Pure64 as the bootloader. Since functions can't exported, however, the only reason this works is because the resulting main function just happens to be at location address 0. Which stinks, partly because of the ugly warning from ld every time I build. The main function takes NO arguments and never returns, so calling conventions don't matter; all that's needed is the ability to export the main label
> 
> Does Myrddin support inline asm at all? If so, I could just put the export statement myself.
> 
> On Wed, Jan 14, 2015 at 1:28 AM, Ori Bernstein <ori@xxxxxxxxxxxxxx> wrote:
> Right now that's not possible. The problem is that we don't function calls
> that conform to the C ABI. Changing that would definitely be a good idea.
> 
> The place to fix this would be in 6/isel.c, in the gencall function, as
> I remember. The biggest challenge with doing this change is figuring out
> how to handle structs that get packed into registers. Eg:
> 
>     type t = struct
>         a : int32
>         b : byte
>     ;;
> 
> extracting 'b' is going to have to happen by shifting/anding the register
> that the struct gets passed in, as far as I recall. Don't think it would be
> too hard, although I suspect it would be an intrusive change. Probably would
> just need a subregister location type added. Will have to think later.
> 
> Varargs also gets messy if you use the C calling conventions, but I think
> that gordian knot can be sliced by just saying "ditch C style varargs". I
> want the varargs to pass some type information vector anyways, which would
> make the ABI incompatible, so we can get away by saying 'all varargs go on
> the stack'. The goal is that things like:
> 
>     std.put("% % %", 'c', 123, "asdf")
>     std.packedbytes('a', "b", 1.234)
> 
> and so on would work.
> 
> On Tue, 13 Jan 2015 15:52:43 -0600
> Ryan Gonzalez <rymg19@xxxxxxxxx> wrote:
> 
> > I'm trying to export a Myrddin function so it can be seen from C. Is this
> > possible? Scanning the source, all I found was an unused export keyword.
> >
> > --
> > Ryan
> > If anybody ever asks me why I prefer C++ to C, my answer will be simple:
> > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was
> > nul-terminated."
> > Personal reality distortion fields are immune to contradictory evidence. -
> > srean
> > Check out my website: http://kirbyfan64.github.io/
> 
> 
> --
> Ori Bernstein <ori@xxxxxxxxxxxxxx>
> 
> 
> 
> -- 
> Ryan
> If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated."
> Personal reality distortion fields are immune to contradictory evidence. - srean
> Check out my website: http://kirbyfan64.github.io/