Re: Exporting functions

[Ryan Gonzalez <rymg19@xxxxxxxxx>]

On Wed, Jan 14, 2015 at 10:29 PM, Ori Bernstein <ori@xxxxxxxxxxxxxx> wrote:

> 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.
>

Ok..that looks like it'll work. Thanks for the help!


>
> 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>
>
>


-- 
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/