Adding new function signatures to parrot's NCI call list
Dan Sugalski
return type, the rest are the parameter types. Use "p" for any
generic "i've stuffed a struct pointer into a PMC" type. Do please
only add in signatures for functions you're actually going to call
(or are adding if you're adding in a full library) as we'd rather not
have nci.o get *too* big...
If I've got things set properly, nci.c should get rebuilt if either
call_types.txt or build_nativecall.pl change, but do feel free to add
in other checks, just to make sure. I'd hate to have too much stale
stuff hanging around.
Also, at the moment I can't test this. (The dynaloading on Darwin
only works on .bundle files not .dylib files (I think I know how to
fix this), and my linux box's headers are all screwed up somehow) So
if someone wants to pick a target library and try it out, well,
that'd be fine with me.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
James Mastros
> Pretty straightforward. Edit call_types.txt. First parameter's the
> return type, the rest are the parameter types. Use "p" for any generic
> "i've stuffed a struct pointer into a PMC" type. Do please only add in
> signatures for functions you're actually going to call (or are adding if
> you're adding in a full library) as we'd rather not have nci.o get *too*
> big...
document this at the top of call_types.txt, along with what it's for?
(If you can't, at least rename the thing nci_types.txt, so it's mildly
clear what it's for.)
Not that I mean to complaign -- this looks very cool indeed. (Actualy
messing with parrot for real again is on my todo project list, after a
couple of other things that I'll probably never really complete. For
now, I'm just reading along and occasionaly kabitzing.)
-=- James Mastros
Dan Sugalski
>On 11/25/2002 9:02 PM, Dan Sugalski wrote:
>>Pretty straightforward. Edit call_types.txt. First parameter's the
>>return type, the rest are the parameter types. Use "p" for any
>>generic "i've stuffed a struct pointer into a PMC" type. Do please
>>only add in signatures for functions you're actually going to call
>>(or are adding if you're adding in a full library) as we'd rather
>>not have nci.o get *too* big...
>Could you setup build_nativecall.pl to ignore #-style comments, and
>document this at the top of call_types.txt, along with what it's
>for? (If you can't, at least rename the thing nci_types.txt, so it's
>mildly clear what it's for.)
I'll go look--it should already do this, and I thought I committed
those changes, but they might not've gone in.
James Mastros
> At 1:02 AM -0500 11/27/02, James Mastros wrote:
>
>> On 11/25/2002 9:02 PM, Dan Sugalski wrote:
>>
>>> Pretty straightforward. Edit call_types.txt. First parameter's the
>>> return type, the rest are the parameter types. Use "p" for any
>>> generic "i've stuffed a struct pointer into a PMC" type. Do please
>>> only add in signatures for functions you're actually going to call
>>> (or are adding if you're adding in a full library) as we'd rather
>>> not have nci.o get *too* big...
>>
>> Could you setup build_nativecall.pl to ignore #-style comments, and
>> document this at the top of call_types.txt, along with what it's for?
>> (If you can't, at least rename the thing nci_types.txt, so it's
>> mildly clear what it's for.)
>
>
> I'll go look--it should already do this, and I thought I committed
> those changes, but they might not've gone in.
You did, my bad, sorry. (Though a note about what these types we're
specifiying are for would be useful.)
-=- James Mastros
Leon Brocard
> Also, at the moment I can't test this
OK, I've had a go. I'm basing the following on the code you mentioned
at http://use.perl.org/~Elian/journal/9147 (of course, you should know
better than to use "exit" in parrot assembler ;-) and basic code at
http://www.libsdl.org/intro/usinginit.html:
loadlib P1, "libSDL-1.2.so.0"
print "Loaded...\n"
dlfunc P0, P1, "SDL_Init", "i"
print "dlfunced...\n"
set I5, 48 # SDL_INIT_AUDIO|SDL_INIT_VIDEO
invoke
unless I5, OK
print "SDL_Init failed!\n"
end
OK:
print "SDL_Init worked just fine\n"
end
I get:
Loaded...
dlfunced...
../parrot: relocation error: /usr/lib/libSDL-1.2.so.0: undefined symbol: pthread_mutexattr_init
Well, the C code on the page works fine, but of course you have to
link it with -lpthread. How would I do this for the parrot code?
Leon
--
Leon Brocard.............................http://www.astray.com/
scribot.................................http://www.scribot.com/
.... (Tagline 3 of 12) - Collect them all!
Gopal V
> Loaded...
> dlfunced...
> ../parrot: relocation error: /usr/lib/libSDL-1.2.so.0: undefined symbol: pthread_mutexattr_init
>
I don't know if this is twisting the knife in the wound ... but it works
for me ...
[gopal@mushroom parrot]$ perl assemble.pl acme.pasm > acme.pbc
[gopal@mushroom parrot]$ ./parrot acme.pbc
Loaded...
dlfunced...
SDL_Init worked just fine
[gopal@mushroom parrot]$
> How would I do this for the parrot code?
You can't link in static libs (.a) with parrot or any other form of
dlopen/dlsym ... Check if you have a libpthread.so somewhere ... if
you have , then it will work .... (glibc-devel has it ,IIRC) ..
And one *minor* point ... you'll need to do this in an Xterm .. the
SDL libs need X11 to initialize ..
Gopal
--
The difference between insanity and genius is measured by success
Dan Sugalski
>
>Loaded...
>dlfunced...
>../parrot: relocation error: /usr/lib/libSDL-1.2.so.0: undefined
>symbol: pthread_mutexattr_init
>
>Well, the C code on the page works fine, but of course you have to
>link it with -lpthread. How would I do this for the parrot code?
You'd need to do that at parrot build time. If it were almost any
other library I'd say you could just loadlib the thing, but pthreads
tends to want to be part of the initial program load.
Dan Sugalski
Leon Brocard
> pthreads tends to want to be part of the initial program load.
FYI adding -lpthreads to C_LIBS and rebuilding parrot makes it work
for me. Now to get the hand of the signatures...
Leon
--
Leon Brocard.............................http://www.astray.com/
scribot.................................http://www.scribot.com/
.... Help! Police! That guy stole my .sig! STOP!!! THIEF!!!
Leon Brocard
> Now to get the hand of the signatures...
Ah, well, I gave up on SDL as it was a little complicated. Instead, I
played with curses. Please find attached a cute little curses life
program loading and calling curses at runtime with dlfunc.
Oh, and I made the shape a small spaceship as it's more interesting.
[It's a bit of the pain the way it stomps over registers all the time,
though ;-]
Leon
--
Leon Brocard.............................http://www.astray.com/
scribot.................................http://www.scribot.com/
.... 43rd Law of Computing: Anything that can go wr...
Dan Sugalski
>Leon Brocard sent the following bits through the ether:
>
>> Now to get the hand of the signatures...
>
>Ah, well, I gave up on SDL as it was a little complicated. Instead, I
>played with curses. Please find attached a cute little curses life
>program loading and calling curses at runtime with dlfunc.
>
>Oh, and I made the shape a small spaceship as it's more interesting.
Leon, you're really scary, y'know that? :)
>[It's a bit of the pain the way it stomps over registers all the time,
>though ;-]
There are ways to get around that, and there are some inefficiencies
in the implementation there. I think we can work around some of
those--I am rather tempted to have invoke promise not to alter
non-parameter registers or something so you don't have to pushall
every time you make a call to what could be assumed to be an atomic
and non-parrot function.
Piers Cawley
> At 4:45 PM +0000 12/5/02, Leon Brocard wrote:
>>Leon Brocard sent the following bits through the ether:
>>
>>> Now to get the hand of the signatures...
>>
>>Ah, well, I gave up on SDL as it was a little complicated. Instead, I
>>played with curses. Please find attached a cute little curses life
>>program loading and calling curses at runtime with dlfunc.
>>
>>Oh, and I made the shape a small spaceship as it's more interesting.
>
> Leon, you're really scary, y'know that? :)
I've suggested he work on getting Readline working next. Then, once
he's done the zmachine loader and got a zmachine opcode set up and
running...
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Nicholas Clark
> Dan Sugalski <d...@sidhe.org> writes:
>
> > At 4:45 PM +0000 12/5/02, Leon Brocard wrote:
> >>Leon Brocard sent the following bits through the ether:
> >>Ah, well, I gave up on SDL as it was a little complicated. Instead, I
> >>played with curses. Please find attached a cute little curses life
> >>program loading and calling curses at runtime with dlfunc.
> >>
> >>Oh, and I made the shape a small spaceship as it's more interesting.
> >
> > Leon, you're really scary, y'know that? :)
>
> I've suggested he work on getting Readline working next. Then, once
> he's done the zmachine loader and got a zmachine opcode set up and
> running...
and then all get digressed into playing http://astray.com/Bookshop.z5
(see
http://london.pm.org/pipermail/london.pm/Week-of-Mon-20010924/005441.html
)
Nicholas Clark
Piers Cawley
> At 4:45 PM +0000 12/5/02, Leon Brocard wrote:
>>Leon Brocard sent the following bits through the ether:
>>
>>> Now to get the hand of the signatures...
>>
>>Ah, well, I gave up on SDL as it was a little complicated. Instead,
>>I played with curses. Please find attached a cute little curses life
>>program loading and calling curses at runtime with dlfunc.
>>
>>Oh, and I made the shape a small spaceship as it's more interesting.
>
> Leon, you're really scary, y'know that? :)
>
>>[It's a bit of the pain the way it stomps over registers all the
>>time, though ;-]
>
> There are ways to get around that, and there are some inefficiencies
> in the implementation there. I think we can work around some of
> those--I am rather tempted to have invoke promise not to alter
> non-parameter registers or something so you don't have to pushall
> every time you make a call to what could be assumed to be an atomic
> and non-parrot function.
Doesn't that rather invalidate the whole 'caller saves' principle?
Leopold Toetsch
> Dan Sugalski <d...@sidhe.org> writes:
>>There are ways to get around that, and there are some inefficiencies
>>in the implementation there. I think we can work around some of
>>those--I am rather tempted to have invoke promise not to alter
>>non-parameter registers or something so you don't have to pushall
>>every time you make a call to what could be assumed to be an atomic
>>and non-parrot function.
> Doesn't that rather invalidate the whole 'caller saves' principle?
The 'caller save' principle is IMHO subotimal. The caller doesn't know,
how a sub is implemented, so has always to save everything. When the
called sub is responsible for preserving the environment, only a minimal
set of needed registers can be saved in the sub.
I would vote for above "non-parameter registers are preserved".
BTW imcc needs some extensions:
- subroutine return values in registers are OUT params WRT the invoke
call, which imcc isn't aware of
- popX/clearX/restoreall do change registers, though this isn't flagged
in the opcode.
imcc assumes, that all registers are preserved over function calls.
leo
Piers Cawley
> Piers Cawley wrote:
>
>> Dan Sugalski <d...@sidhe.org> writes:
>
>>>There are ways to get around that, and there are some inefficiencies
>>>in the implementation there. I think we can work around some of
>>>those--I am rather tempted to have invoke promise not to alter
>>>non-parameter registers or something so you don't have to pushall
>>>every time you make a call to what could be assumed to be an atomic
>>>and non-parrot function.
>
>> Doesn't that rather invalidate the whole 'caller saves' principle?
>
>
> The 'caller save' principle is IMHO subotimal. The caller doesn't
> know, how a sub is implemented, so has always to save everything.
> When the called sub is responsible for preserving the environment,
> only a minimal set of needed registers can be saved in the sub.
Whichever style you choose will be suboptimal. However, if you move to callee
saves you lose the possibility of adding tail call optimization at a
later date, and some subs will end up saving registers that don't
need saving. (I also wonder how continuations are going to work with
callee saves since the continuation needs to get the register set
back into a sane state and it gets created at call time.)
I coness I'm somewhat bemused to see any sub doing 'save all', a
given sub knows which registers it uses, and they are the only ones
that it needs to save (because it's callers have already saved
anything that's important to them).
> I would vote for above "non-parameter registers are preserved".
>
> BTW imcc needs some extensions:
> - subroutine return values in registers are OUT params WRT the invoke
> call, which imcc isn't aware of
> - popX/clearX/restoreall do change registers, though this isn't
> flagged in the opcode.
>
> imcc assumes, that all registers are preserved over function calls.
Looks like IMCC needs fixing.
Dan Sugalski
Nope. There's nothing wrong with having a set of more stringent
rules. Since invoke is for C functions that we know are C functions
and thus we can't tail-call into them (and they aren't likely to use
any parrot registers) it seems a reasonable optimization.
I think the general rule is "When you cross an interpreter/C
boundary, you must assume the caller has no clue what you might do
and you must be careful" or something like that.