Re: Pondering argument passing
On Sep-26, Leopold Toetsch wrote: Dan Sugalski [EMAIL PROTECTED] wrote: [ splatted function args ] ... For this, I think we're going to need a setp Ix, Py op which does indirect register addressing. Done. Cool, thanks! With it, I've been able to get a bit farther. Found a minor bug where it multiply defines a label if you make two calls. I'm not sure IMCC is going to be able to autogenerate the prototyped and nonprototyped versions of the callee's entry code from the same set of .param declarations. sub f3($a, $b, ?$c) If that is converted to .param $a .param $b .param $c then IMCC is going to get very unhappy when you call it without a prototype and only pass it two arguments. If it is converted to .param $a .param $b .param remaining_args .local $c if remaining_args 0 $c = shift remaining_args then I'll need to pass in the extra remaining_args array in all calls, prototyped or non-. That's not a huge deal, and it fixes this problem. But you'll hit it again if you call f3 unprototyped with f3(3, b = 4); Named arguments cause a lot more trouble than that, but I still don't want to go into that yet. But the above example should be enough to demonstrate that one set of .param declarations won't be enough unless we add more metadata to the declarations, and that feels like it might be too perl6-specific. How bad would it be to do: .pcc_sub _main .pcc_non_prototyped # . # . # . # code to place params into the registers that they would # be in if called with a prototype. I'm not sure if IMCC # can autogenerate any of this or not. # . # . # . # IMCC inserts a jump to the main body of the routine .pcc_prototyped .param _SV_a .param _SV_b .param _SV_c # This is a little strange. The caller knows the prototype, # so can pass in an undef if the 3rd argument wasn't given. # But the callee may have a different default value in # mind than undef, and if it's an expression then it # probably needs to be evaluated by the callee in its # local environment. We could create a new UnpassedArg PMC, # or we could add something to the calling conventions # so that you know how many arguments were actually # passed. .pcc_body # subroutine body .end The non-prototyped section would want to use the same _SV_? variables, so perhaps the prototyped section should come first.
Re: Pondering argument passing
Steve Fink [EMAIL PROTECTED] wrote: With it, I've been able to get a bit farther. Found a minor bug where it multiply defines a label if you make two calls. Oh well, allways these nasty complicate programs, that want to call a sub twice :) Fixed, thanks. I'm not sure IMCC is going to be able to autogenerate the prototyped and nonprototyped versions of the callee's entry code from the same set of .param declarations. This is currently implemented as the unprototyped case. If a sub does expect to be called either prototyped or non-prototyped, the proto specifier of the .pcc_sub SHOULD be omitted. The entry code then looks at CI0 and does either case. So we should specify, what to do with wrong param counts or wrong types. pcc.t has some examples for this (labeled unproto or exception). I think we als need the concept of a default value (for at least Pie-Thon's sake - does Perl6 also have default values?) sub f($a, $b=1, $c=Default); ... f(42); leo
Re: Q: vtable - can, isa, does
Dan Sugalski [EMAIL PROTECTED] wrote:
The full explanation is:
can - checks to see if an object can perform a specific, single
method. (A parent class may provide them)
isa - checks to see if the named class is in the inheritance
hierarchy for the object
does - checks to see if the object implements the named collection of
methods. (Often, but not always, called an interface)
Thanks for the thorough description.
So the question arises, if and how we implement these vtables for all
classes/*.pmc. Do we want to have the methods too? Or should Ccan check
a bitfield, if the PMC can do that corresponding vtable.
WRT Cdoes: This could be one more flag in the pmc definition:
pmclass PerlArray extends Array need_ext does array {
Any proposals for interface names:
array
hash
scalar
sub (invocable)
struct
...
leo
Re: cvs commit: parrot/classes orderedhash.pmc pmc2c.pl unmanagedstruct.pmc
Dan Sugalski [EMAIL PROTECTED] wrote:
[ unmanagedstruct.pmc ]
+INTVAL set_integer(INTVAL value) {
Managed struct does use this vtable (set_integer_native) to set the
size.
Anyway: Do you have any specs for these two classes. How do we handle
structs? What are the mentioned triples for init_pmc?
leo
Disassembler issues and URM
Hi, I've been playing with Parrot for the last two days trying to get the disassembler working, but I was not very successful. As I mentioned earlier in my patch email there were some issues in the debug.c file due to some uninitialized variables. The second SEGFAULT I get happens due to some strange memory management issues I don't fully understand. The disassembler calls Parrots own sprintf function to throw simple chars out on a string when it gets another op decoded (Backtrace is below). What I found out till now is that it is somewhere deep down in the smallobjects.c and the arena structures. It seems as if the initialized size of 1024 is not big enough and he tries to reallocate some more objects, but that does not work somehow. Though he sets the new size to 4096 the free_list somehow points to a wrong value after some additions, thus returning a bad ptr in get_free_object and thus creating a bad n value that leads to the SEGV. As I said, I have no clue what is happening there, sound like an uninitialized value problem, but I couldn't make out where that happened. BTW this happens when I try to disassemble one of my example programs (testmmu2.urm) that has quite a long bytecode. With shorter pbcs this does not happen, as it the overflow is connected to the amount of ops used. BTW, I managed to write a urm.in for the Configure.pl script and made my urmc package relative to the parrot root (assuming it in languages/urm). Now it is completely integrated into the Parrot build process and should be even more platform independent than e.g. perl6, which has hardcoded / in it's perl6.in :-) http://perl.thiesenweb.de/urmc-0.3.tar.bz2 Have fun, Marcus Program received signal SIGSEGV, Segmentation fault. 0x08134102 in get_free_object (interpreter=0x819bb60, pool=0x81bc438) at smallobject.c:143 143 arena-dod_flags[ n ARENA_FLAG_SHIFT ] = #0 0x08134102 in get_free_object (interpreter=0x819bb60, pool=0x81bc438) at smallobject.c:143 #1 0x080f6ae4 in get_free_buffer (interpreter=0x819bb60, pool=0x81bc438) at headers.c:55 #2 0x080f6eb3 in new_string_header (interpreter=0x819bb60, flags=8192) at headers.c:194 #3 0x0808c735 in string_make (interpreter=0x819bb60, buffer=0x816bb8c, len=2, encoding=0x816e140, flags=8192, type=0x8198ba0) at string.c:234 #4 0x080f8926 in Parrot_vsprintf_c (interpreter=0x819bb60, pat=0x816bb8c %c, args=0xba88 6) at misc.c:49 #5 0x080fbb14 in PIO_printf (interpreter=0x819bb60, s=0x816bb8c %c) at io/io.c:664 #6 0x080c7b78 in Parrot_disassemble (interpreter=0x819bb60) at embed.c:525 #7 0x0804980c in main (argc=2, argv=0xbb14) at disassemble.c:54 -- - |Marcus Thiesen ICQ# 108989768| - | www.thiesenweb.de | - 28A7 37CC AE2C BB6C D56D 8A3D E614 E56B 7546 75F2 signature.asc Description: This is a digitally signed message part
Re: Pondering argument passing
On Sep-28, Leopold Toetsch wrote: Steve Fink [EMAIL PROTECTED] wrote: I'm not sure IMCC is going to be able to autogenerate the prototyped and nonprototyped versions of the callee's entry code from the same set of .param declarations. This is currently implemented as the unprototyped case. If a sub does expect to be called either prototyped or non-prototyped, the proto specifier of the .pcc_sub SHOULD be omitted. The entry code then looks at CI0 and does either case. So we should specify, what to do with wrong param counts or wrong types. pcc.t has some examples for this (labeled unproto or exception). I was arguing that this isn't enough. We need the set of parameters to really be different in the two cases, so we need two sets of .param statements, not just one. I think we als need the concept of a default value (for at least Pie-Thon's sake - does Perl6 also have default values?) sub f($a, $b=1, $c=Default); ... f(42); Yes, this is what I was talking about in the big block comment in the sample code at the end of my last message. Perl6 does have them. I don't know whether Perl6 or any other language we want to be nice to has *non-constant* defaults. If so, and if we want direct support for them, then it means we need to evaluate them in the context of the callee. Which is the natural way to do it anyway, but having the caller fill in default values for a prototyped call could work around some of the issues with argument passing that would otherwise require more native support to handle. (I'd prefer the native support, whatever it might be.) There's the issue of detecting whether a parameter was passed or not, in order to decide whether to fill in the default value. (See my last message for more discussion of this.)
IMCC parsing weirdness
I am getting strange behavior from IMCC if the first line after .pcc_sub is a comment. It seems to misinterpret things and ends up emitting a restore_p op that triggers a No entries on UserStack! exception. I've attached a diff to languages/imcc/t/syn/pcc.t, but I'm not sure if that's the right place for the test. I'm looking at fixing this now, but the grammar rules relating to this are a bit hairy. I've eliminated the existing shift/reduce conflict by assigning precedence to a dummy rule, but I'm still working on changing the grammar to accept stuff in the parameter list.
Re: IMCC parsing weirdness
On Sep-28, Steve Fink wrote: I've attached a diff to languages/imcc/t/syn/pcc.t, but I'm not sure if that's the right place for the test. Oops. Except CVS is being very flaky right now, so the patch hadn't been written to the file before I sent it. Oh well. I'm committing a fix for the bug, as well as resolving all shift/reduce conflicts via precedence. I'll also commit the test. I'll let someone else move it around if they want. I didn't bother allowing line and filename comments in the middle of .param sections, although I suppose that might make sense if you're splitting your parameter declarations across multiple lines. Oh well.
Status of IMCC Examples A Win32 API Call Example
Hi, Went to look in languages/imcc/examples the other day and noticed there were only a few examples in there, and that sample.imc doesn't even work. Is there a reason for a lack of examples or should I have a crack at writing some? BTW, tonight I managed to get Parrot to call a few Win32 APIs successfully using NCI (not that it won't have been done before, but it was the first time for me... ;-)). I've attached an example that shows how to call the MessageBoxA function. Noticed there is a Qt NCI example, and I thought maybe a Win32 one would be nice too. :-) For those who use POW (Parrot On Win32) there will be an updated version available tomorrow made from latest CVS tree, and I'll put 0.0.11.2 up also (currently have 0.0.11). Sorry for such a mish-mash of things in one email. Take care, Jonathan win32nci.imc Description: Binary data
RE: Status of IMCC Examples A Win32 API Call Example
Cool, can I write my software with it now? ;) BTW, tonight I managed to get Parrot to call a few Win32 APIs successfully using NCI (not that it won't have been done before, but it was the first time for me... ;-)). I've attached an example that shows how to call the MessageBoxA function. Noticed there is a Qt NCI example, and I thought maybe a Win32 one would be nice too. :-)
Re: [PATCH] Getting ICU to build on OS X
Please also send a copy of this to the ICU developers. (See the ICU website/documentation.) We need to try and make as few changes as possible to ICU, or it will become a _nightmare_ to maintain. By making sure our local changes get sent upstreadm it will keep our life simpler in the future. -R Michael Scott (via RT) wrote: # New Ticket Created by Michael Scott # Please include the string: [perl #24043] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=24043 This patch gets ICU to build on Mac OS X. It works around a gcc -E -MMD bug. -- attachment 1 -- url: http://rt.perl.org/rt2/attach/65328/48724/2c2ce5/mh-darwin.patch
