Re: Exporting functions

[Ori Bernstein <ori@xxxxxxxxxxxxxx>]

No, but taking a slice off a pointer doesn't do runtime checks, so you can
always scan to the end of a C string, and take a slice. Example below.

I should toss this into libstd :)

	const cstrconvp = {p
		var i

		i = 0
		idx = p castto(intptr)
		while ((idx + i) castto(byte#))# != 0
			i++
		;;
		-> p[:i]
	}

Note: Untested.

On Wed, 14 Jan 2015 22:05:05 -0600
Ryan <rymg19@xxxxxxxxx> wrote:

> 
> 
> Ori Bernstein <ori@xxxxxxxxxxxxxx> wrote:
> >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.
> 
> I used to do this, but got out of the habit when, during kernel writing, GCC kept whining about main not returning an int. My only worry is that, in the future, Myrddin will get a compiler intristic to optimize main or something and break my kernel. :)
> 
> > 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'.
> >
> 
> Ok! I think I'll use the pkg technique. Thanks!
> 
> On another note: is it possible to index a slice WITHOUT runtime checks? Right now, I'm doing something like this to index strings (typing off the top of my head, so it likely isn't what I actually wrote):
> 
> const index = {s, i
>     -> ((s castto (uint64)) + i castto (byte#))#
> }
> 
> I can't help but feel like this is a hack.
> 
> Then again, writing a kernel is a hack anyway!
> 
> >
> >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/
> 
> -- 
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
> Check out my website: http://kirbyfan64.github.io/
> 


-- 
Ori Bernstein <ori@xxxxxxxxxxxxxx>