Porting parrot on PDA
hello people! I'm really interested in porting parrot to PDA (well, PocketPC at least). some days ago I stumbled upon CeGCC (a cross compiler for PocketPC), which is basically a windows port of gcc (both cygwin and mingw32 flavours) that produces ARM executable code. I started playing with it, trying to use it to build parrot; with just a few hours hacking, I managed to build a miniparrot.exe that actually runs (sort of) on PocketPC. I understand that what I've done is just a drop in the ocean, and that a real porting would require tons and tons of work more, but at least this first effort looks promising :-) now I will try to report briefly what I've done so far. I obviously started with "perl Configure.pl --ask", from a Cygwin bash shell. mainly, I told Configure to use "arm-wince-pe-gcc" instead of just "gcc" as the compiler, linker etc. and I disabled completely jit, threads and all the frills. of course, all the tests which relies on a test executable failed; they did compile indeed, but the executable couldn't be run on the desktop PC. that's the biggest problem, I suppose :-) so, I had to manually adjust lots of #define in config.h, has_headers.h, and later some minor fixes to feature.h, io.h and thread.h. I had problems with compiling src/stm/backend.c, turned out that the parameters to PARROT_ATOMIC_PTR_GET in atomic.h were reversed (this may be a bug not related to building with cegcc, I don't know); and ATOMIC_SET isn't defined, so I provided an optimistic (!): #define ATOMIC_SET(a,b) (a).val = b; I had to adjust also src/platform.c (the bits that come from config/gen/platform/generic/exec.c) because cegcc doesn't provide fork, execlp and waitpid. I used vfork, execvp and wait instead (I know, the last one isn't equivalent at all -- a problem for later!). at this point, miniparrot.exe was built. the process can't go much further because, obviously, that miniparrot doesn't execute on the desktop PC. anyway, I tried copying the executable on the device, and it does run! here's a transcript from my PocketConsole session: \CF Card\dada> miniparrot -h Couldn't create message pipe \CF Card\dada> something apparently didn't work with regard to thread handling. but it shouldn't be that hard to fix. the biggest problem, as mentioned, is that the build process needs fundamentally to execute stuff (built for the device, that is). this would require some serious hacking. IIRC, there are command line tools to copy and even execute files directly on the device. this would make possible to grab somehow the output and keep the build system happy. I will try, if I can, to search for a viable solution in the next days. if there's anybody else interested who wants to join the effort, let me know :-) cheers, Aldo
Porting parrot on PDA -- work in progress
whoa there!
I've managed to build parrot for the PocketPC. yes, really. I hacked
just a little the Configure process - now it _really_ compiles test
executables, run them on the PDA and gather the result. this wasn't
really hard.
I had a half-written Perl XS extension which uses RAPI to communicate
with the PDA. I just worked on it a little and prepared a simple script
which does the trick. all I had to do was to add a parameter to
_run_command in lib/Parrot/Configure/Step.pm which simply does:
if($remote) {
$command = "$^X runonpda.pl $command";
}
runonpda.pl is my simple script in this case. once I have my RAPI
extension on CPAN, this could eventually be turned into a proper patch
to Parrot's Configure.
the resulting files needed just a few fixes, mainly because Configure
pulls out information about headers from Perl's Config.pm (which of
course, in this case, isn't just right).
there are also minor glitches with threads and OS system calls, but they
can be solved by creating a directory in config/gen/platform (eg. cegcc
or whatever) and writing there the correct code.
furthermore, the Configure process uses $^O here and there, and this
should eventually be replaced by an --arch=something parameter to
Configure.pl (which defaults to $^O, of course).
my parrot does indeed run some of the examples/pasm files. I tried
hello.pasm, fact.pasm, xml_parser.pasm, they all run just fine.
now, from what I understand looking at the Makefile, this parrot should
be used to generate a lot of .pbc files that constitute the "core"
Parrot library. this is going to be a real pain, because while it's true
that I can run parrot on the PDA, all the directory structure (eg.
runtime/parrot/library) is not there at all.
so I'm really puzzled about what to do next. is this parrot.exe alone
worth something (except for running .pasm files, that is)? should I
transfer the whole parrot directory to the PDA and build the library
there, by hand?
I would appreciate any feedback :-)
cheers,
Aldo
Cross-compiling Parrot
back in 2004, Dan Sugalski wrote: http://www.nntp.perl.org/group/perl.perl6.internals/2004/09/msg25521.html nowadays my effort of porting Parrot to the PocketPC platform, as you may have suspected, force me to reopen the question. there is, I know, a lot of work to be done. and this will surely require a lot of time. and, very probably, much more knowledge than I currently have. but I'm willing to learn, and to live long enough to complete the task. I intend to start submitting patches that do not break things that already work. for example, everything that is pulled out from Perl's %Config will need to be pulled out from somewhere else if, and _only if_, we are currently cross-compiling. (well, this is the plan. I can't exclude that something somewhere may break for some obscure reason, so please bear with me in advance :-). before I start dirting my hands with code, I'm here to ask you: 1) does anybody have objections to patching the current build system for cross-compilation (even "yes, but not now because..." objections)? 2) does anybody already have a .plan or something in mind about it (so that I may either learn from what others have thought, or avoiding reinventing some wheel)? should I be warnocked, I will silently assume "no" and "no" as answers to the preceeding points :-) cheers, Aldo
Re: Cross-compiling Parrot
jerry gay ha scritto: On 2/20/07, Aldo Calpini <[EMAIL PROTECTED]> wrote: 1) does anybody have objections to patching the current build system for cross-compilation (even "yes, but not now because..." objections)? no objection here! this is a long-desired feature, and is currently unavailable. although i don't have a pocketpc to test on, i'll do my best to help. for years, the dependence on perl 5's configure probes has bothered me--just not enough to fix it. i'm glad to see this porting effort will renew that effort. that's all very good. 2) does anybody already have a .plan or something in mind about it (so that I may either learn from what others have thought, or avoiding reinventing some wheel)? [...] since this style hasn't been practiced as a rule in the past, it'll take some time to get used to--for all of us. but i believe it's the safest way to proceed to modify the critical-yet-undertested subsystem that is configure. are you willing to work in the way i described? how does the project team feel about this approach? I have no problems with this approach. modulo the fact that I'm an absolute beginner in the fine art of version control (some CVS, a little bit of SVN, but just basic checkout-checkin), so I have no idea how to go about branching and merging and all that stuff. but I'll find the time to RTFM on my own :-) speaking briefly about a technical plan--there have been discussions of a way forward in the past. the general consensus is that miniparrot be designed to be ANSI C-only, with as few platform-specific extensions as possible, and zero dependence on perl's configure. after miniparrot is built, it can be used to perform the remainder of the build tasks in a portable manner. this gives us a lot of code reuse, and should make future porting efforts easier. however, there's a lot of this design left to flesh out, and none of it is implemented. i think this is the right design, but we need to find one or more ways to get there, and work towards that. however that discussion merits one or more separate message threads. yuck. shortly after I sent my message I stumbled upon http://rt.perl.org/rt3/Public/Bug/Display.html?id=31136. and my first thought was "oh, no". having the build system done by a miniparrot isn't going to be convenient for cross-compiling. right now, I successfully built parrot tweaking the source here and there, but as I said in another message, the next steps in the Makefile (building the core Parrot library and finally installing the product) are going to be a huge pain. cross-compiling a simple, standalone, test executable to check for features, headers etc and running it on the target platform is, well, easy enough. on the other hand, running something (the miniparrot) which probably expects to have the whole build directory at hand, this isn't easy. copying files to and from the target device and generally exchanging data is slow, unsafe, and ultimately just a hack. add to this that we're talking about PDAs, which are usually much slower and severely resource-constrained (both in RAM and storage) than a regular desktop. for PocketPC's sake, using a miniparrot to do most of the build is a malus, not a bonus. but this wouldn't affect, for example, the Nokia N800 port, which uses scratchbox as an environment. this, however, comes at a cost: you can build for the N800 _only_ on a *nix host platform. probably developing something like scratchbox for CeGCC would be the Right Thing To Do. but that's a completely different story (and a completely different effort, alas). all in all, this is something that will need to be considered very carefully. and I guess I've ranted enough about it now :-) cheers, Aldo
Re: Cross-compiling Parrot
Joshua Isom ha scritto: Using perl 5's configure probes also somewhat limits us to how the vendor distributed perl. It should also be considered that we can't rely on perl5 being available, especially since we intend to replace it eventually, so rewriting all the perl to support cross compiling would likely not be the best thing. I don't second that. I agree that relaying on Perl5's configure is not the way to go, but I don't see any problem in using Perl5 as _the tool_ to build. while it's true that Parrot aims at replacing it, Perl5 is going to be there for years to come. and what alternatives are there? Perl5's own configuration/build system is based on bash and make, and they are far more less available than Perl5 itself. IMO, using Perl to configure is a much more powerful, maintainable, work-everywhere solution than some autoconf-based stuff. If we create a new configure system, we can essentially have two configuration methods in the trunk, and have tests for the new one to be sure it's working and portable before trying to get everyone to start using it. well, I didn't intend to build a whole new configure system from scratch. I'm afraid this would be far more expensive than the current amount of Free Time I have to spend on the project. I've noticed a lot that mentions miniparrot being used for building parrot, but at the same time, we don't have anything to work with to know just how limited miniparrot should be. Perhaps a step to work for before rebuilding the configure subsystem(which theoretically should be in pir to get rid of perl5 dependence), is to get an actual miniparrot working? Currently miniparrot just seems to be a macroparrot with a miniconfig. If we can't realistically get a miniparrot, maybe it should be considered if building a miniparrot for configuration is a good idea. Instead of rewriting everything now in perl5 to support cross compiling, maybe we should dive in and try to see if we can get it rewritten in pir. After all, we're getting more pir programmers than perl5 programmers it seems. woot! I am _not_ going to become a pir programmer, sorry :-) seriously, I'm not really sure that targeting "pir programmers" is a desiderable thing. I mean, in the long term, how many people are going to really learn pir and use it as a programming language? Parrot maintainers, sure, and HLL compiler authors, but how many of them there will be, as opposed to Perl(5..6) programmers? cheers, Aldo
Re: Cross-compiling Parrot
Allison Randal ha scritto: We do. Unfortunately we can't rely on Perl 5 for the configure system. It may seem like an easy way to gain cross-compilation in the short term, but in the long term it will hurt us. Miniparrot is the right way to go. It certainly needs work, though. As you're thinking of solutions think of what miniparrot would need to become cross-compiler aware. ok. I can't say that that I fully understand why, but I trust you. > woot! I am _not_ going to become a pir programmer, sorry :-) You'll be surprised at how easy it is to pick up, especially if you have experience with dynamic languages. There are, of course, plenty of Parrot tasks that don't require PIR skills, but don't give up before you try it. You might like it. please, don't get me wrong. I have absolutely nothing against PIR, is just that I'm so damn fluent in Perl5 :-) I follow Parrot from the day it was born, I even wrote some - crude, I admit it - code in PASM something like 4 years ago (http://dada.perl.it/shootout/parrot_allsrc.html). but when the first IMCC appeared, I felt it was just too much. maybe PIR nowadays isn't as complicated as it was when I left it, I don't know. I will certainly give it a closer look. That being the case, let's start you out submitting patches. It's where everyone starts, and having a mentor to review patches at first is a great way to pass along the knowledge of the experienced Parrot hackers. For a change this size, we generally start with a proposal, review it as a group, and then dive into implementation. In this case, given the nature of the problem and your experience with the codebase, go ahead and start experimenting with code, but write up your plans as you go. We'll do an architecture review before too long to see how well the idea fits with the overall plans for Parrot. I just sent a first patch today (which is small and mostly^W harmless), commenting what will be my next step(s). I have no "big plan" yet, it's just a configure-fix-patch-reconfigure cycle, so I try to approach obstacles as they pop out. when I come to the point that I will need a "stronger" patch, something that may impact the overall architecture, I intend to sit down and think about it for a while, write it down and submit it for your approval. thank you for your attention and wise words :-) cheers, Aldo
Re: [perl #41724] [BUG] miniparrot fails to build on strawberry perl
Jerry Gay (via RT) ha scritto: i suspect there's trouble with the platform-specific c/h files, given the nature of the warnings during build. the configure/make output is below. the only relevant warning I see is: config/gen/platform/win32/exec.c: In function `Parrot_Exec_OS_Command': config/gen/platform/win32/exec.c:182: warning: passing arg 2 of `_execvp' from i ncompatible pointer type this seems to be generated by the difference between 'char **' and 'char* const*'. I don't think this is a great problem. Invoking Parrot to generate runtime/parrot/include/config.fpmc --cross your fing ers ./miniparrot.exe config_lib.pasm > runtime/parrot/include/config.fpmc '.' is not recognized as an internal or external command, operable program or batch file. make: *** [runtime/parrot/include/config.fpmc] Error 1 these last lines seem to suggest that miniparrot.exe was in fact built. the problem, I think, is that make is trying to call miniparrot prepending './', which is sh-style and does not work under Windows CMD. you may have better luck running make from a cygwin shell. or perhaps you could try mingw32-make instead of make as Configure.pl suggests? on the other hand, I had a totally different experience using strawberry perl to build parrot. it doesn't work at all, make groks because of backslashes in paths in the Makefile (had to change them to forward slashes), libparrot.dll refuses to build because, apparently, g++ is unable to link correctly (it says: "cc1.exe \: no such file or directory"). YMMV. cheers, Aldo
[JIT] bsr/ret in native code
hello there,
in one of my endless tours inside the JIT world, I came up with this idea
which seems to give a major speed increase.
basically, I'm substituting the Parrot method for subroutines (push the
current address in the call stack and then jump) with a plain native
x86 ASM call instruction. and of course, the ret instruction is just a
plain native ret instruction.
that way I'm completely avoiding the call stack, just relaying to the
CPU internal stack for this.
to make it work, I had to JIT all the 2-parameters eq/ne instructions
to perform a ret on successful comparison instead of a pop and goto.
this is of course a major change in the internal working of the interpreter
when using the -j option, so I'm not sure it is a Good Thing. you would
not be able, for example, to inspect the call stack from inside a Parrot
program anymore.
anyway, this is a little sample of the implementation:
Parrot_bsr_ic {
emit_call_op2(jit_info, *INT_CONST[1]);
}
Parrot_ret {
emitm_ret(NATIVECODE);
}
Parrot_eq_i_i {
emitm_movl_m_r(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
&INT_REG[1]);
emitm_cmpl_r_m(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
&INT_REG[2]);
emitm_jxs(NATIVECODE, emitm_jne, +1);
emitm_ret(NATIVECODE);
}
there are of course a lot more eq_X_X and ne_X_X combination, but they're
all similar to this.
the emit_call_op2 in jit.h is just a slight variant of emit_call_op which
only uses 32 bit displacement for backward calls (don't ask me why, but it
seems to work like this):
static void emit_call_op2(Parrot_jit_info *jit_info, opcode_t disp){
long offset;
opcode_t opcode;
opcode = jit_info->op_i + disp;
if(opcode <= jit_info->op_i) {
offset = jit_info->op_map[opcode].offset -
(jit_info->native_ptr - jit_info->arena_start);
emitm_calll(jit_info->native_ptr, offset - 5);
return;
}
Parrot_jit_newfixup(jit_info);
jit_info->fixups->type = JIT_X86JUMP;
jit_info->fixups->param.opcode = opcode;
emitm_calll(jit_info->native_ptr, 0xc0def00d);
}
if anybody sees a problem with this approach, please let me know, otherwise
I'll go on with the patch.
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: Parrot Glossary - COW
Markus Laire wrote: > I've been following this list for a month, but havn't yet learned what COW > really means. It's used so often that perhaps it should be added to Parrot > Glossary. I'll give my try, but I'm no expert at all. feel free to correct me if I'm wrong. COW stands for Copy On Write. it means that when you have to copy a string, the "real" string to be copied (eg. its content, eg. the bytes) is not really copied in memory with the copy operation. rather, the new string is marked as COW, and it still points to the original string. when you read that string, you are "redirected" to the original one. but when you want to write something to the string (eg. modify it), then the system notes the COW flag and performs the actual copying of bytes (possibly a part of them, if you are modifying only part of the string). this approach saves memory, because you can create as many copies of a string as you want, without allocating it many times. unless you modify them, at least. it's also usually a great speed boost, because copying a string is performed in O(1) time, instead of O(n) - where n is the size of the string. hope this helps :-) cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: [PATCH] Key.pmc and some core.ops functions
Josef Höök wrote: > Aldo Calpini ( alias dada on irc ) had a couple of good arguments > why having a key.pmc. I just want this patch in because i need it > for my soon to come matrix.pmc. that's embarassing, but it must have been someone else. I only ranted on IRC about tuple.pmc and some other braindead ideas, and while I followed the discussion about key.pmc, I didn't provide any good argument ;-) cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: PARROT QUESTIONS: Keyed access
Leon Brocard wrote: > I think ParrotTuple would make a great first project for anyone > who wants to learn more about PMCs. It will also be fairly simple > and small, so if lots of docs were also included it would make > an ideal PMC to learn from in future. Any takers? ;-) me, time permitting :-) should it be ParrotTuple.pmc or just tuple.pmc? and if this is going to be ParrotTuple.pmc, are we going to rename array.pmc in ParrotArray.pmc etc. etc.? I prefer just tuple.pmc. cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
minitutorial on submitting patches
this is a little tutorial about submitting patches (should be added to a FAQ, or somewhere where it's handy for people like me that tend to forget everything :-). if there's something missing or incorrect, feel free to let me know: 1. do a diff -u of the file(s) you want to patch (note: Win32 users will probably need -ub) 2. redirect the output to a file (any name will do, .patch extension is conventional) 3. create a new email message 4. set the recipient to: [EMAIL PROTECTED] (note there's no need to CC the mailing list, it will find its way through it) 5. prepend [PATCH] to the subject 6. be very, very informative about what you're doing, both in the subject line and the message body 7. attach the patch file you generated in step 2 (DON'T paste the content in the body, attach the file!) 8. send and wait patiently. cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
tutorial on submitting patches
this is a little tutorial about submitting patches (should be added to a FAQ, or somewhere where it's handy for people like me that tends to forget everything :-). if there's something missing or incorrect, feel free to let me know: 1. do a diff -u of the file(s) you want to patch (note: Win32 users will probably need -ub) 2. redirect the output to a file (any name will do, .patch extension is conventional) 3. create a new email message 4. set the recipient to: [EMAIL PROTECTED] (note there's no need to CC the mailing list, it will find its way through it) 5. prepend [PATCH] to the subject 6. be very, very informative about what you're doing, both in the subject line and the message body 7. attach the patch file you generated in step 2 (DON'T paste the content in the body, attach the file!) 8. send and wait patiently. cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: [PATCH] usleep, sleep(num)
Dan Sugalski wrote: > I like this, and want it to go in--I think it's a capability > we should provide. However... Until it works on Win32 we need > to wait. Can someone running a Win box grab this and get a win > version going? When we have that, this can get committed. I'm a little late on this ;-) there's nothing special to do on Win32. the current Parrot_sleep implementation on this platform is: Sleep(seconds * 1000); so to get a millisecond sleep just remove the * 1000 part. it works on any Windows from 95 up. I don't have time now to patch Steve's patch, if nobody else can do it, I'll do it next week. cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: [PATCH] usleep, sleep(num)
Nicholas Clark wrote:
> Does Microsoft give you (well, us) a select() implementation that
> really does honour the microsecond field of the struct timeval
> it's passed?
AFAIK, microseconds are honoured only on sockets, not on filehandles.
> I seem to remember reading somewhere that the most portable way of
> achieving a sub second sleep was to call select() for that period
> waiting on no file descriptors.
well, that was perl5, and guess what the implementation does in
src/win32/win32sck.c ?
if (!(rd || wr || ex)) {
if (timeout)
Sleep(timeout->tv_sec * 1000 +
timeout->tv_usec / 1000); /* do the best we can */
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: negative index in arrays
Stephen Rawls wrote: > since I want the Tuple pmc to do the same thing in > this respect as the PerlArray pmc. just my opinion, but I don't want this. it would be PerlTuple then. let's keep this stuff at a higher level. the only and one reason I see because one would implement tuples instead of arrays is: speed. no need to cope with dynamic memory allocation, no need to grow or shrink, se there should also be no need to check for syntactic sugar like negative indices. cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: [perl #15904] Configure broken on windows 9x
Mr. Nobody wrote: > The windows 9x command.com shell dosen't recognize > 2>&1 so it ends up passing "2" as an argument to the > compiler, which fails because there's no such file. this is no news. you can't even build Perl on 9x. IMHO, *build* platform targets should not include 9x. build it on NT/2000/XP and then feel free to use the binary on 9x (as Perl actually does). cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: tuple algebra (was: negative index in arrays)
Stephen Rawls wrote: > Also of note, instead of having TUPLE1 + TUPLE2 act as > arrays, and return the sum of their sizes, I am > treating it like this: (a1, a2, ... , an) + (b1, b2, > ... , bn) = (a1 + b1, a2 + b2, ... , an + bn) makes sense to me (and certainly adds some spice to the cause of tuples instead of arrays :-). you should also consider the case TUPLE1 + 5 which should return (a1 + 5, a2 + 5, ... , an + 5). what do you do if TUPLE1 and TUPLE2 are of different length? changing subject again... how is tuple storage implemented? do they contain only integers (or whatever), or is the base type definable? I ask this because I thought it would be nice to have a 4-tuple of type char. this will nicely represent an IP address, for example (or do we need an ipaddr.pmc? ;-). cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
resize_array (PerlArray)
take this little assembler program:
new P1, .PerlArray
set P1, 100
bsr GETLEN
set I0, P1[0]
print "P1[0]="
print I0
print "\n"
bsr GETLEN
set I0, P1[1]
print "P1[1]="
print I0
print "\n"
bsr GETLEN
end
GETLEN:
set I0, P1
print "length="
print I0
print "\n"
ret
it prints:
length=100
P1[0]=0
length=100
P1[1]=0
length=10001
fetching an element out of bound changes the
length of the array. but should this really happen?
why does perlarray.pmc act like this:
if (ix >= SELF->cache.int_val) {
resize_array(interpreter, SELF, ix+1);
}
instead of:
if (ix >= SELF->cache.int_val) {
value = pmc_new(INTERP, enum_class_PerlUndef);
return value->vtable->get_integer(INTERP, value);
}
are there any reason for this that I can't see or does it
just need a patch?
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: resize_array (PerlArray)
Dan Sugalski wrote: > At 5:28 PM +0200 8/1/02, Aldo Calpini wrote: >>fetching an element out of bound changes the >>length of the array. but should this really happen? > > Because that's the way Perl's arrays work. Joys of > autovivification. I have to disagree. the corresponding Perl script does not show this behaviour: my @a = (undef) x 100; print "length=", scalar(@a), "\n"; print "a[0]=", $a[0], "\n"; print "length=", scalar(@a), "\n"; print "a[1]=", $a[1], "\n"; print "length=", scalar(@a), "\n"; the output is: length=100 a[0]= length=100 a[1]= length=100 cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
debugger.pod
hello everybody, here is my rough draft of the documentation for the Parrot debugger. please review it (expecially the boilerplate stuff like TITLE, HISTORY, etc. -- I don't know if I have properly followed convention) (and if there is one) and tell me if this should be sent as a patch. I'm afraid I didn't completely understand what the 'load' and 'disassemble' commands do or are good for (Daniel gave some hint, but I'm a slow one :-). please note that I'm going (well, don't really know *when*, but I'm going :-) to work on debug.c to implement some stuff. this is, from memory, what I plan to do: - implement 'list b' to list breakpoints - change 'delete' so that it accepts line numbers instead of breakpoint numbers - add a 'stack c' subcommand to examine control stack - change 'list' so that it prints a 'b' next to lines that are breakpointed - add error checking here and there if someone is already working on this, or has other brilliant ideas, please speak now. cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print; debugger.pod Description: Binary data
Re: resize_array (PerlArray)
John Porter wrote: > It all depends. :-) > > [...] > > Perl has to autoviv if it has to drill down. good point. but since we don't have multidimensional array access right now (at least AFAIK), this seems to be a non-issue. I don't know if p6 will autovivify the way p5 does (and I hope not). IMHO, PerlArray.pmc should behave the way I suggested: if the index is out of bound, returns undef tout-court. I have the patch under my toes ;-) cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: [perl #16098] First draft of PerlScalar PMC
Peter Gibbs wrote: > This version is (hopefully) functionally equivalent to PerlUndef, > i.e. it acts as an uninitialised scalar. When assigned a value, > it changes itself to the appropriate type (PerlInt/PerlNum/ > PerlString). The current level of functionality is therefore > sufficient to use it for creation of new PMCs. I presume this doesn't take into account double-typed scalars (eg. $!). is this something we need to think about? > Incidentally, how would a PerlScalar be returned to undef status? what about this? new P0, .PerlScalar new P1, .PerlUndef set P0, P1 cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: [PROPOSAL] interface for custom pmc functions
Josef Hook wrote: > It's a fact that we have a problem with pmc's that has custom > functions which dosent fit into the vtable. Therefore i suggest > we add a pointer in pmc struct that points to a function list, we already have find_method and invoke, they just need to be implemented :-) I was thinking about tweaking pmc2c.pl to build a stash for each PMC on init phase, so that the code in method_util.c can be put to use. what do others think about this? cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
[prepatch] PerlHash iterator
I have implemented a simple hash iterator, but I'm not
sure that the logic is correct. this shows how the PMC
behaves actually:
new P1, .PerlHash # build a simple hash
set P1["foo"], 1
set P1["bar"], 2
set P1["baz"], 3
dec P1 # reset the iterator
LOOP:
unless P1, END # when false, iterator has ended
# (eg. there's no current key)
set S0, P1 # fetch the current key
print S0# print it
set I0, P1[S0] # fetch the current value
print "="
print I0# print it
print "\n"
inc P1 # iterate to next key
branch LOOP
END:
end
and the output is:
baz=3
foo=1
bar=2
I have implemented the following functions in hash.c:
void hash_reset(Interp *interpreter, HASH *hash);
void hash_next(Interp *interpreter, HASH *hash)
STRING *hash_get_current(Interp *interpreter, HASH *hash)
and the following PMC vtable methods:
STRING* get_string () {
STRING* s;
s = hash_get_current(INTERP, (HASH*) SELF->data);
if(s == NULL)
return (STRING*) undef->vtable->get_string(INTERP, undef);
else
return s;
}
void decrement () {
hash_reset(INTERP, (HASH*) SELF->data);
}
void increment () {
hash_next(INTERP, (HASH*) SELF->data);
}
INTVAL get_bool () {
if(hash_get_current(INTERP, (HASH*) SELF->data) == NULL)
return 0;
else
return 1;
}
what do you think about it? it is worthy a patch, or should I
change my approach?
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
Iterator.pmc (was: set_p_p)
Mattia Barbon wrote:
>> set P1, P0 # tells P1 that he's going to iterate P0
>
> This looks like a kludge. IMHO the correct way of getting an iterator
> is having the aggregate return it (say, using find_method/invoke);
that's a correct assumption, and when find_method/invoke will be
implemented, there will be something like that. but this doesn't
change much in the Iterator implementation. it will be just another
way (probably the preferred one) to get an Iterator.
either way, the PASM language is not intended for humans(*), doesn't
strive for inner elegance and perfect orthogonality, so kludges are
legal as long as they gain us speed :-)
(*) read: it is not intended to be something you will have fun(**)
programming in, there's Perl for this.
(**) but then, there are people actually having fun programming in
Befunge, so this statement could not apply at all :-)
> and the iterator does not need to be of class Iterator, it just needs
> to behave like one. Otherwise your Iterator needs to know all the
> types it has to iterate over, which is bad.
that's not the case. the Iterator *need* to be of class Iterator, as
I'm going to demonstrate. as I implemented it, it actually doesn't need
to know all the types it has to iterate over, as I'm going to show.
on the other hand, the current Iterator PMC does not actually
*implement* an iterator, but in some sense it behaves like one. it's
the aggregate itself that needs to implement the methods to iterate
its own data structure, so what you say is partly correct.
the design of Iterator.pmc has the following objectives:
1. provide an abstract (read: aggregate-independant) interface to
iterate an aggregate
2. provide an object that is external to the aggregate, so that
one aggregate can have multiple iterators
point 1. is accomplished through vtable entries. the aggregate
should implement the following functions for Iterator to work:
INTVAL iterator_sizeof()
void iterator_reset()
void iterator_set(void *data)
void iterator_get(void *data)
PMC* iterator_get_current()
void iterator_next();
once an Iterator is "assigned" to an aggregate PMC, it calls its
iterator_sizeof() method.
INTVAL iterator_sizeof()
this should return the amount of memory required to store and mantain
iterator state information. for example, iterating an Array only
requires an INTVAL (the current index in the array), so sizeof(INTVAL)
will be returned. iterating an Hash requires two values (the bucket
chain index and a pointer to the current HashBucket, but these are
details), so PerlHash's iterator_sizeof() will return
sizeof(HashIndex) + sizeof(HASHBUCKET*). the Iterator PMC allocates
the proper amount of memory so that it can mantain its own state
information (see point 2.).
void iterator_set(void *data)
this sets the aggregate's iterator state to the given "data", eg. the
amount of memory allocated with iterator_sizeof().
void iterator_get(void *data)
this gets the aggregate's iterator state so that the Iterator PMC can
update its own "data".
PMC* iterator_get_current()
void iterator_reset()
void iterator_next()
these are the methods that actually does the iteration.
as you can see, all the iteration stuff is done by the aggregate
PMC class itself. the Iterator PMC provides opcode mapping for
its action (eg. inc for next, etc.), as well as storage for its
own state. this way, an aggregate (which really does the iteration)
does not need to mantain such information for multiple iterators.
it only needs to receive the relevant information from the Iterator
who's currently acting on the aggregate.
the iterator updates its own memory from the aggregate on each
operation, as the following pseudocode shows (hope it's clear :-):
reset {
AGGREGATE->iterator_reset()
ITERATOR->data = AGGREGATE->iterator_get()
}
next {
AGGREGATE->iterator_set(ITERATOR->data)
AGGREGATE->iterator_next()
ITERATOR->data = AGGREGATE->iterator_get()
}
get_current {
AGGREGATE->iterator_set(ITERATOR->data)
return AGGREGATE->iterator_get_current
}
this accomplishes point 2. and shows why Iterator needs to be a class
of its own.
the implementation could surely be improved, and it certainly need
to(*), but I hope the design does make some sense :-)
(*) just to make an example, this approach is absolutely not
thread-safe.
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
[web-PATCH] parrot logo
whoever put the parrot logo on www.parrotcode.org, make your penances, because you are in sin! you will find attached a replacement for that logo which doesn't hurt like a kick in the eye, and above all does s/GIF/PNG/g :-) cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print; multicol.png Description: PNG image
how to use MultiArray?
I couldn't find any example of using a MultiArray PMC. I tried on my own, but failed miserably. from what I've seen, it seems that is impossible to properly initialize a multidimensional MultiArray. I've tried this: new P1, .MultiArray, 1000 set P1[0;0], 1 set P1[0;1], 2 set P1[0;2], 3 print "(0,0)=" set I0, P1[0;0] print I0 # prints: # (0,0)=3 end every assignment changes whe whole P1[0] array. it seems to lose the 2nd dimension somehow, probably because the "dimension" member of the PMC was never initialized. how do I go on using this? what do we need to make it work? cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
[perl #17405] [PATCH] correct make pdb on Win32
# New Ticket Created by "Aldo Calpini" # Please include the string: [perl #17405] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=17405 > this one patches the Makefile to correctly build a "pdb.exe" on Win32 (it should also do the Right Thing on each platform that has an extension for executables). the Makefile was producing a file named "pdb" which could not be executed on Windows (I had to rename it "pdb.exe" after the make). cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print; -- attachment 1 -- url: http://rt.perl.org/rt2/attach/38013/30904/7e2db4/pdb_exe.patch pdb_exe.patch Description: pdb_exe.patch
t/src/* broken under Win32
the tests under t/src currently fail on Win32 (with MSVC++ 6.0). the first problem is that it needs another build step (make shared) which is not mentioned anywhere. linking the programs require a libparrot.lib which is not built by the standard make target. probably it should be a prerequisite for 'make test'. after doing this, I tracked down the following problems: basic.t 2/2 basic_2.obj : error LNK2001: unresolved external symbol _internal_exception intlist.t 1/4 intlist_1.obj : error LNK2001: unresolved external symbol _intlist_get intlist_1.obj : error LNK2001: unresolved external symbol _intlist_push intlist_1.obj : error LNK2001: unresolved external symbol _intlist_new intlist.t 2/4 intlist_2.obj : error LNK2001: unresolved external symbol _intlist_get intlist_2.obj : error LNK2001: unresolved external symbol _intlist_pop intlist_2.obj : error LNK2001: unresolved external symbol _intlist_push intlist_2.obj : error LNK2001: unresolved external symbol _intlist_new intlist.t 3/4 intlist_3.obj : error LNK2001: unresolved external symbol _intlist_get intlist_3.obj : error LNK2001: unresolved external symbol _intlist_pop intlist_3.obj : error LNK2001: unresolved external symbol _intlist_push intlist_3.obj : error LNK2001: unresolved external symbol _intlist_assign intlist_3.obj : error LNK2001: unresolved external symbol _intlist_unshift intlist_3.obj : error LNK2001: unresolved external symbol _intlist_new intlist.t 4/4 intlist_4.obj : error LNK2001: unresolved external symbol _intlist_pop intlist_4.obj : error LNK2001: unresolved external symbol _intlist_unshift intlist_4.obj : error LNK2001: unresolved external symbol _intlist_shift intlist_4.obj : error LNK2001: unresolved external symbol _intlist_get intlist_4.obj : error LNK2001: unresolved external symbol _intlist_push intlist_4.obj : error LNK2001: unresolved external symbol _intlist_new comments anybody? cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: [perl #17683] [PATCH] Fixes segfault in pdb
Jürgen Bömmels wrote: > Hi, > > When you use pdb and hit just you get a segfault. Thats > quite anoying especially if you are used to gdbs behaviour. > > The attached patch fixes this by just ignoring empty lines. this doesn't seem to me how pdb is supposed to work. docs/debugger.pod says: A blank line always repeat the last command entered. and that's also perl -d behaviour. either fix it differently, or patch the documentation too :-) cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: the getting started guide
Erik Lechak wrote: > Yep I cut and pasted it right from my console. I'll download the newest > realease and try it again and try v1.2. If someone could tell me where > to get cvs for windows without all the GUI that would be great. www.cygwin.com full-blown command-line CVS. you won't miss *nix again ;-) cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: getting started guide in pod
Erik Lechak wrote: > Just wondering: What would another documentation style have to > provide to make it an acceptable replacement for pod? being pod. you gotta love it ;-) cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: [RFC] Buffer/PMC unification, variable/value vtable split, tied scalars
Leopold Toetsch wrote: > Attached is a test program showing some features, how a PMC could look > like in the future. and where's the attachment? cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
[perl #18141] [PATCH] determine PARROT_STACK_DIR on Win32 with Visual C++
# New Ticket Created by "Aldo Calpini"
# Please include the string: [perl #18141]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18141 >
due to a bug in config/auto/stackdir.pl, Configure.pl
was unable to determine PARROT_STACK_DIR when using
Visual C++.
the error was to use ${cc_exe_out} as a parameter to
$link, instead of ${ldout}, which resulted in producing
the wrong executable name for the test program. as a
result, Parrot was unable to compile (syntax error in
dod.c).
the attached patch fixes the problem.
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/40714/32817/be0ada/stackdir.patch
stackdir.patch
Description: stackdir.patch
Re: How to portably link on Win32 (all flavors), OS/2 and VMS?
Andy Dougherty wrote: > but I'm unsure what to put for link_exe_out for each of the three > compilers mentioned in config/init/hints/mswin32.pl, nor for the > compilers used under OS/2 and VMS. config/init/hints/mswin32.pl already defines what you need. is called 'ld_out' (also see my recent patch to stackdir.pl). cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: Should memory be washed?
Leopold Toetsch wrote:
> Appended is a test program that shows timings (i386 w rdtsc) and
> the limit, where malloc changes strategy to use mmap and returns
> zeroed memory.
I don't know if it helps, but there are the results on my machine,
using Windows XP Pro and Cygwin 1.3.10 and GCC 2.95.3:
# gcc -o chkm chkm.c -O3 && ./chkm
size1.mal2.mal3.mal memset clean
1 8500 1188 9320 0
2 8908 932 892 664 **
4 6828 904 928 276 **
8 6828 904 936 276 **
1610520 968 928 612 **
32 8796 908 912 840 **
64 8092 988 916 892 **
128 7584 1032 936 932 **
256 6328 1052 936 1088 **
512 6952 1236 940 1096 **
102481784 1408 944 1912 **
204855984 1108 944 3940 **
40965381213592 1044 7928 **
81925197615932 98028880 **
163845698815520 99670516 **
327686078016584 952 159332 **
655366087616580 1104 356616 **
1310726249216440 964 748300 **
2621446866817628 996 1545984 **
5242886915217604 924 3272504 **
10485767432438948 992 6678812 **
20971528660438012 1052 14211056 **
4194304 10617240908 1060 458976804 **
8388608 14727674432 1144 56008064 **
# gcc -o chkm chkm.c malloc.c -O3 && ./chkm
size1.mal2.mal3.mal memset clean
1 7104 300 2040 0
2 3964 188 1800 0
4 3304 188 1800 0
8 3264 256 1720 0
16 6508 164 1800 0
32 2112 388 168 1500 **
64 3496 260 192 904 **
128 3268 208 296 1304 **
256 3276 392 272 1232 **
512 1924 492 196 1344 **
1024 266478572 268 1676 **
2048 303631248 116 3420 **
40966331214524 144 6588 **
81925450815632 11626584 **
163845272414888 17273844 **
327685833614632 164 165624 **
655365768014344 164 421396 **
1310725816415748 236 757964 **
262144 24952849220498360 0
524288 16081672180537280 0
1048576 17321271464669640 0
2097152 21448895112983400 0
4194304 296548 171728 1611600 0
8388608 405532 283444 2918920 0
to compile with Visual C++ I had to change the rdtscl macro to:
#define rdtscl(low) \
{ \
_asmrdtsc \
_asmmov dword ptr [low], eax \
}
the low word seems to be in eax instead of edx, don't know why.
and these are the results:
# cl -nologo -o chkm_vc.exe chkm_vc.c && chkm_vc
chkm_vc.c
size1.mal2.mal3.mal memset clean
1 2288 668 3520 0
2 5068 456 348 176 **
4 2040 552 304 260 **
8 1936 380 280 172 **
16 2864 368 296 172 **
32 1408 756 328 172 **
64 1360 408 308 188 **
128 1260 500 376 228 **
256 1276 828 396 292 **
512 1424 400 304 568 **
1024 3936 1080 420 1168 **
204839664 432 388 4492 **
40964941212760 420 7684 **
81924251215484 52415476 **
163846743626780 54475100 **
327684368025584 532 167956 **
655364639226052 125328 359224 **
131072574562632427228 788760 **
26214452196 11665626800 1598200 **
5242885872029900175000 0
10485762650416048151680 0
20971523856427296159040 0
41943043400827608158040 0
83886084048024464254920 0
the results are apparently the same with -Ox (maximum opts).
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: DOS filename collisions
Mr. Nobody wrote: > There are some files in parrot that have names common in the first 8 > characters. This will cause problems if someone tries to compile Parrot on > DOS. Is DOS an intended target, or should we not worry about this? my vote is NO. let us bury 8.3 very, very deep in the ground. cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: [PASM] PerlHash and keys
Leopold Toetsch wrote: > There is a nextkey_keyed mentioned in pdd02_vtables.pod, which would > almost be all to implement aggregate iterators. Missing is IMHO how to > reset (start) an iteration. > Also not too long ago, there was some proposal WRT an iterator class. I was the proposer. I have written an Iterator PMC back in the ol' 0.0.8 days, but then I was distracted and never finished my work. I will try to reimplement my addition to 0.0.9 and submit a patch ASAP (probably after 07 jan ;-). > This proposal needed more vtable functions. yes, it does. > Also not specified: how to attach an iterator to an aggregate. this was solved with the implementation of the 'assign' op. cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
A6: objects and/or types (was: P6FC)
Simon Cozens wrote:
> ...and I don't know if macros are actually objects and can be tossed
> around, or if they're just part of the compilation process.
they have their proper place in the diagram Larry put in A6.
furthermore, he says:
"These syntactic forms correspond the various Routine types in the
Code type hierarchy"
so Macro seems to be at least a type. which leads me to the question:
is Macro "also" a class? and which is the difference between a type
and a class? hm, I guess this will be answered in A12, so I'll
probably have to wait on this.
I also have another question (probably related, and probably also for
later). consider this:
sub mygrep( Code &block, [EMAIL PROTECTED] is rw ) {...};
sub mygrep( Block &block, [EMAIL PROTECTED] is rw ) {...};
sub mygrep( Routine &block, [EMAIL PROTECTED] is rw ) {...};
sub mygrep( Sub &block, [EMAIL PROTECTED] is rw ) {...};
sub mygrep( Method &block, [EMAIL PROTECTED] is rw ) {...};
is something like this allowed? and what is the meaning then? if logic
serves me correctly, this shouldn't work:
sub mygrep( Routine &block, [EMAIL PROTECTED] is rw ) {...};
mygrep { $_ < 2 }, 1, 2, 3;
because { $_ < 2 } is a Block, not a Routine! it should be written
like this:
sub smaller_than_two ($value) { return $value < 2 }
mygrep smaller_than_two, 1, 2, 3;
but this doesn't seem to make much sense. one should probably have
said 'Code &block' (or '&block' alone, which I suppose is just the
same), but then what's the use of 'Routine', 'Sub', 'Method' etc. as
types?
also, it's not clear to me the distinction between isa-relationship
and namespace. I see that 'Rule' (and I presume 'Sub', 'Routine',
'Code', etc.) are all type names, but I wonder if 'Bare' is a type of
its own -- or it is 'Block::Bare'? the latter sounds much better :-)
in my class hierarchy I mixed 'probable' isa-relationships (eg. Sub
isa Routine isa Code) with 'probable' proper namespace hierarchy (eg.
Exception::Control::return, not return isa Control isa Exception).
and this is probably very, very wrong.
or maybe I'm just playing with dangerous toys that aren't intended for
a little kid like me :-)
> I think Type should be called Value, and that arrays should possibly
> be a mixin of lists, but apart from that it looks fine. Oh, and you
> missed out Grammars; ...
thanks, applied :-)
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
P6FC
hello everybody, I'm just a poor newbie here, so please bear with me :-) while reading the last Apocalypse I thought that maybe time has come to write things down (like the recent effort on properties), so I started to put down a tentative class hierarchy of the Perl6 language (I call it P6FC for Perl6 Foundation Classes, but the name may (should? :-) very well change). you can find what I've come up so far here: http://dada.perl.it/p6fc.html it's just plain ASCII for now, but I plan to have an XML file with metadata attached (eg. bibliography, apocalypse number, references and such) and a dynamically produced SVG (or something else) graph. probably I'm not the right person to mantain this (I already have my problems following p6-internals and I'm not even subscribed to p6-language), but I just wanted to throw the idea out. feel absolutely free to take over the whole stuff or reject this in disgust :-) cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: AW: P6FC
Murat Ünalan wrote: > A very good idea, but i am afraid that this ML isnt the right > audience. > > PS: But before reinventing a wheel, i would like to suggest to > adopt the .NET/Java object hierarchy. uhm. either I am completely wrong or you are totally out of track. I really don't understand what you're talking about :-) anyway, on http://dada.perl.it/p6fc.html you find now a pretty GraphViz image accompanied by the XML data source (I'm digging up the references right now) and the script I used to produce the diagram. any (possibly meaningful) feedback will be very appreciated. cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: OT: Will the State of the Onion be posted online?
Robert Spier wrote: >> Sorry for a slightly off-topic post, but will Larry's State of the Onion >> be posted online soon? > > Yes. sorry to reiterate the argument, but will also a text transcript of the talk be posted online? the slides are beautiful, but without a few words of explanation they are "scary" at least :-) cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: ad Timer
Leopold Toetsch wrote:
> Attached is a test program, showing an implementations for multiple
> timers. GNU/linux only, but implementing the platform interface (and the
> sighandler/message queue) shouldn't be too hard.
don't know if it's worth something, but this is how your timer program
could look like under Win32.
rename timer_win32_c.txt to timer_win32.c and compile with:
cl timer_win32.c /link user32.lib
I had to comment out the signal(SIGALRM, sig_alarm_handler); line and
add a PeekMessage/DispatchMessage routine in the while loop.
the rest of the Win32-specific code is in the "platform interface"
section.
I realize this is really ugly, but Win32 doesn't seem to have support
for alarms, so you have to relay on windows messages instead. if
someone can come up with a better way to do it, I'm really curious to
see it :-)
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;/*
* itimer test
*/
/* #include */
#include
#include
#include
#include
#include
volatile sig_atomic_t got_alarm = 0;
typedef struct timer_t {
int ticks;
int value;
int repeat;
int run;
int nr;
struct timer_t *next;
struct timer_t *prev;
} timer;
timer *rtimer = 0;
void add_timer(timer *t) {
timer *next = rtimer;
rtimer = t;
t->next = next;
if (next) {
t->nr = next->nr + 1;
next->prev = t;
}
else
t->nr = 1;
}
void del_timer(timer *t) {
timer *next = t->next;
timer *prev = t->prev;
if (prev)
prev->next = next;
else
rtimer = next;
if (next)
next->prev = prev;
free(t);
}
timer * new_timer(void) {
timer *t = calloc(1, sizeof(timer));
add_timer(t);
return t;
}
typedef unsigned int UINTVAL;
typedef double FLOATVAL;
UINTVAL gcd(UINTVAL a, UINTVAL b) {
UINTVAL q = 0;
UINTVAL c = 0;
while (b != 0) {
q = (UINTVAL)floor( (FLOATVAL)a/b );
c = a - b*q;
a = b;
b = c;
}
return a;
}
void
sig_alarm_handler(int i) {
got_alarm = 1;
}
/* platform interface */
typedef struct win32_timer_t {
UINT_PTR id;
UINT ms;
} win32_timer;
VOID CALLBACK proc_sys_timer_ms(
HWND hwnd,
UINT uMsg,
UINT_PTR idEvent,
DWORD dwTime
) {
got_alarm = 1;
}
void start_sys_timer_ms(void *handle, int ms) {
win32_timer * t = (win32_timer *) handle;
t->id = SetTimer(NULL, 0, ms, proc_sys_timer_ms);
t->ms = ms;
printf("new ms = %d\n",
ms);
}
void stop_sys_timer_ms(void *handle) {
win32_timer * t = (win32_timer *) handle;
KillTimer(NULL, t->id);
free(t);
}
int get_sys_timer_ms(void *handle) {
win32_timer * t = (win32_timer *) handle;
return t->ms;
}
void * new_sys_timer_ms() {
win32_timer *t = calloc(1, sizeof(win32_timer));
t->ms = 0;
t->id = (UINT_PTR) NULL;
return (void *) t;
}
/* end platform interface */
void recalc_ticks(void);
void *handle;
void
do_alarm_handler() {
timer *t;
UINTVAL ms;
int recalc = 0;
ms = get_sys_timer_ms(handle);
for (t = rtimer; t; t= t->next) {
if (!--t->ticks) {
t->run = 1;
if (t->repeat) {
t->ticks = t->value/ms;
if (t->repeat != -1)
t->repeat--;
}
}
}
again:
for (t = rtimer; t; t= t->next) {
if (t->run == 1) {
t->run = 0;
printf("alarm %d\n", t->nr);
/* code run here may add timers, these have t->run = 2 */
goto again;
}
if (!t->ticks && !t->repeat) {
printf("del_timer %d\n", t->nr);
del_timer(t);
recalc = 1;
goto again;
}
}
if (recalc)
recalc_ticks();
}
void p_add_timer(UINTVAL msecs, int repeat)
{
timer *t;
if (!msecs)
return;
t = new_timer();
t->repeat = repeat;
t->value = msecs;
t->run = 2;
recalc_ticks();
}
void p_del_timer(timer *t) {
del_timer(t);
recalc_ticks();
}
void recalc_ticks() {
UINTVAL ms, oms;
timer *t;
oms = get_sys_timer_ms(handle);
printf("gettimer oms = %d\n", oms);
t = rtimer;
if (t) {
t->run = 0;
if (oms && t->ticks)
ms = oms*t->ticks; /* time left */
else
ms = t->value;
if (t->next) {
for (t = t->next; t; t = t->next) {
t->run = 0;
if (oms && t->ticks) {
ms = gcd(oms*t->ticks, ms);
}
else
ms = gcd(t->value, ms);
}
}
printf("new ms %d\n", ms);
again:
for (t = rtimer; t; t= t->next) {
int ot = t->ticks;
printf("t%d oticks %d => ", t->nr, t->ticks);
if (oms && ot)
t->ticks = t->ticks * ((double)oms / (double)ms);
else
t->ti
Re: proposal: use \ as none junction delimeter
Thomas Sandlaß wrote:
my $x = 1|2|3; # any
my $x = 1^2^3; # one
my $x = 1&2&3; # all
my $x = 1\2\3; # none
[...]
if $a && $b { ... } # and
if $a || $b { ... } # or
if $a ^^ $b { ... } # xor
if $a // $b { ... } # err
if $a \\ $b { ... } # nor
Well?
that's all very Huffy (short for Huffmanish), and probably makes a lot
of visual sense to someone used to mathematical logic.
but to someone who's not, well, I'm afraid it just looks *weird*.
cheers,
Aldo
Re: Junctions, Sets, and Threading.
Damian Conway wrote: >@s = 'item' _ [EMAIL PROTECTED]; That's: @s = 'item »_« @x; (just checking that my unerstanding is correct, don't want to be nitpicking :-) assuming that you meant to prepend the string "item" to each element of @x, isn't that: @s = 'item' »~« @x; ? furthermore, given that the operator "hyperates" on one side only, shouldn't this be: @s = 'item' ~« @x; ? cheers, Aldo
Re: scoping functions as list operators?
Stéphane Payrard wrote: # set? I don't think so. my $a, $b, $c set 1..3 ; # alphabetic like and, or, xor? # and what precedence relative to them? well, I'm not sure the feature is good, but I have some idea about the sign that could be used for this :-) we have all sort of verb forms in Perl6 (is, has, does) so the natural choice seems to be: my $a, $b, $c are 1..3; perhaps it could also be made to DWIM for: my @colours are $red, $green, $blue; or, more prosaically, we could coerce the fat pipe operator to work as a slurpy assignment in this case: my $a, $b, $c <== 1..3; # hmmm... am I breaking something here? or we could even just use an hyper-equal: my $a, $b, $c »=« 1..3; if not for low precedence assignment, "are" could still be used as a (low precedence) "plural" type declaration, as in: my $spot, $fido, $billy are Dog; # not Dogs, alas but I'm afraid this wouldn't be terribly useful either. ok, enough ranting. cheers, Aldo
Re: Comma in (sub) traits?
wolverian wrote:
Hello all,
while writing some experimental code with Pugs, I realised that it is a
bit hard for me to parse the following type of declaration:
sub greeting (Str $person) returns Str is export {
"Hello, $person"
}
don't know if it helps, but I guess that you can also write it like
this, if you prefer:
sub greeting(Str $person) {
returns Str;
is export;
"Hello, $person";
}
(this guess is based on something I recall having read in A12 about
classes; if my guess is wrong, I'll be happy to stand corrected :-).
cheers,
Aldo
Re: Optional binding
David Storrs wrote:
Urk. I, for one, will definitely find this surprising. I would have
expected:
x = ; $y = 1; z = 2 3
to obtain what you have expected, you need to explicitly treat the array
as a list of values with the unary splat:
foo($x, [EMAIL PROTECTED]);
But I suppose it's all a question of learning to love the Brave New
World in which arrays are actually objects (sort of).
more to the point, arrays are automagically referenced in scalar context:
@a = @b; # same as perl5
$a = @b; # means $a = [EMAIL PROTECTED] in perl5
$a = [EMAIL PROTECTED]; # means $a = @b in perl5 (more or less)
another thing that may surprise you (it still surprises me, somehow):
sub bar($x, $y, $z) { ... }
# ^ note x is scalar here!
my @coords = (1.0, 3.0, 5.0);
bar(@coords); # wrong
# x => [EMAIL PROTECTED], y => undef, z => undef
bar([EMAIL PROTECTED]); # ok
but then, you could define:
multi sub bar($x, $y, $z) { ... }
multi sub bar(@coords is shape(3)) {
my($x, $y, $z) = @coords;
return bar($x, $y, $z);
}
bar(@coords); # ok now
cheers,
Aldo
Re: Optional binding
Larry Wall wrote:
Or, assuming you might want to generalize to N dimensions someday, just
sub bar ([EMAIL PROTECTED]) {...}
and deal with it as in Perl 5 as a variadic list. I suppose one could say
sub bar ([EMAIL PROTECTED] is shape(3)) {...}
and get checking on the argument count.
if I understand correctly, without using multi subs:
sub bar(@coords is shape(3)) { ... }
bar(@xyz); # ok
bar( [$x, $y, $z] ); # ok
bar($x, $y, $z); # compile-time error
while:
sub bar([EMAIL PROTECTED] is shape(3)) { ... }
bar(@xyz); # ok
bar( [$x, $y, $z] ); # ok
bar($x, $y, $z); # ok
bar <== $x, $y, $z; # still ok
am I right?
cheers,
Aldo
Re: Adding linear interpolation to an array
Dave Whipp wrote:
Does defining the invocant as "Num @self is constant" constrain the application
> of the role to read-only uses of indices?
I don't think you need "is constant". arguments are readonly by default,
unless you give them the "is rw" trait. I guess that "is constant" means
that you can specify the index only using a literal, not a variable, eg:
@test[1]; # ok, 1 is a costant
my $idx = 1;
@test[$idx]; # nok, $idx is not a constant
but I may be wrong.
Does the explicit indexing by an "int" typed value ensure that
it'll be non-recursive under MMD?
you mean "Num" typed value? if so, I guess using an explicitly
non-integer index would make it win under MMD. on the other hand, your
method could even not be called at all with an integer index.
If I later decare a sub as
sub foo ( @in does LinearInterpolation ) { ... }
Would I be able to pass a normal (non-interpolating) array to this sub,
and then access it using non-integer indices (i.e. is the data in the
array independent of the interface through wich it is accessed).
I don't think so. I'm afraid you have to do something like:
sub foo (@in) {
my @_in = @in;
if(! @in.does(LinearInterpolation) ) {
@_in does LinearInterpolation;
}
# go ahead using @_in
...
}
cheers,
Aldo
splat operator and context
I was trying to implement unary * (list flatten or "splat" operator) in pugs yesterday, and I came to the conclusion that I really don't grok how context works in Perl6 (I also really don't grok Haskell, but this is another story...). if I understand correctly, all these are equivalents: my @a = 1,2,3; my @a = (1,2,3); my @a = list 1,2,3; my @a = [1,2,3]; # or does it make @a[0] = (1,2,3)? and all these are too (they make $a a reference to an array): my $a = 1,2,3; my $a = (1,2,3); my $a = list 1,2,3; my $a = [1,2,3]; I'm not sure what the following do (assign 1 to $a maybe?): my $a = [EMAIL PROTECTED]; my $a = *(1,2,3); # or is this a syntax error? my $a = *(list 1,2,3); my $a = *[1,2,3]; and I have absolutely no clue about the following: my *$a = @a; my *$a = [EMAIL PROTECTED]; my *$a = (1,2,3); my *$a = [1,2,3]; thanks for any help. cheers, Aldo
Re: splat operator and context
Juerd wrote: my @a = 1,2,3; my $a = 1,2,3; These are (my @a = 1), 2, 3; (my $a = 1), 2, 3; if I understand precedence correctly. (S03) right, sure. I vaguely remember something about comma instead of parens being the list constructor, but maybe it was just in my fantasy. and thanks for the other clarifications too. to summarize, I think a decent implementation of "splat" should do the following: if the argument to unary * is... a normal value force list context and cast to 1-elem list a list nop an array cast to list an arrayrefderef and cast to list (I don't know if the use of "cast" is appropriate here. looks more like AST munging...). (I don't like @a = []. It makes @a = ([]) be counter-intuitive (parens only group for precedence), and @a = [[]] feels VERY weird. Besides that, it makes @a = $b completely unpredictible if the type of $b is unknown. If it's an arrayref, @a gets all its elements, but if it's a normal value, @a gets only one element. That's a problem for general purpose modules/subs. I guess they could all use @a = [$b], but I find that ugly.) in fact, S03 states: "In list context, a scalar reference to an array does not flatten." so I think @a = [1,2,3] should leave you with @a[0] = [1,2,3]. and you should use one of: @a = *$b; @a = @$b; @a = $b[]; to make @a get all the elements of the arrayref in $b. cheers, Aldo
Re: Strings - takers wanted
Leopold Toetsch wrote: > 1) ICU should be optional > > If configured --without-icu the Makefile shouldn't contain ICU stuff, > and function calls to ICU (mainly in string_primitives) should be > wrapped inside #if PARROT_HAS_ICU. I'm gonna take this one (unless Steven Schubiger is already working on it). just as a generic hint, what should the #else (eg when PARROT_HAS_ICU is not defined) do? a) consider everything ASCII and use the corresponding stdlib function b) always return NULL (or some approximation of NULL) c) complain to STDERR about ICU not being there d) coredump cheers, Aldo
Re: s/true/better name/
John Macdonald wrote: A shotgun brainstorming of possible operator names: well, I didn't follow this thread very closely (and I don't know if it is "officially" closed :-) but I suddenly thought about "yes". what about: $x = not $a or $b; # vs $x = yes $a or $b; $yesno = yes any(@foo) == any(@bar); may not be gramatically correct English, but isn't it intuitive enough? cheers, Aldo
A12: a doubt about .meta, .dispatcher and final methods
hello,
sorry if this has been discussed before, I did a quick search in the
Archive and the summaries but can't find a similar topic.
I've just read A12, and while I really like the inherent orthogonality
of the whole object system as it is (will be) implemented, there is
something that puzzles me. from what I read, it seems that every class
will implicitly call "does Dispatch" (which provides a .dispatcher
method) and "is Object" (which provides a .meta method). (or more
probably, class Object "does Dispatch" itself). so, if this is true, I
guess I could never write a class that does:
class MyClass {
has LethalWeapon $.dispatcher;
method meta { say "$_ is doing meta!" }
}
both of them would make my class pretty useless, I think, since it could
not (correctly, at least) dispatch methods anymore. and I won't be able
to access metadata.
what would Perl6 do in such a case? I think it should complain, and
probably don't let me compile such a class, but what is the underlying
implementation for this? are .dispatcher, .meta (and maybe some others
too) "special" methods that can't be, in any case, overloaded?
and eventually, can I use a similar mechanism in my own classes, that
is, write a "final" method (something like: you can derive from me
however you like, but you can't redefine this method of mine)?
cheers,
Aldo
Re: A12: a doubt about .meta, .dispatcher and final methods
Aaron Sherman wrote:
> However, in existing CPAN modules that I happen to have in my cache at
> the moment:
>
> [...]
>
> So it's not THAT bad.
hmmm... I think you should probably also grep for modules that do something
like:
my $self = {
meta => 'something',
dispatcher => $something,
# ...
};
return bless $self;
if Perl5 objects are to be implemented somewhat 'transparently' in Perl6,
things like:
$obj->{meta}
will become:
$obj.meta
when used from Perl6. or not?
cheers,
Aldo
Re: A12 Versioning
On Mon, 2004-04-26 at 16:20, Richard Proctor wrote:
> Issues:
>
> 1) Why does this only use Version and Author? Suppose there are versions
> for different oses or that use other particular libraries that are wanted
> or not?
personally, I think this should be handled in the class itself.
you always "use DBI", don't "use DBI-(Any)-(Any)-MSWin32" or "...-linux"
or "...-whatever". class name, version and author(ity) seem to me a good
set to univocally identify a class.
> 2) Shouldn't all these properties just be in a hash against the module
> rather than some having special significance? Others can then be simply
> added as appropriate.
see below.
> 3) Why is the information positional rather than by keyword property?
> use Dog :version«1.2.1» :author«JRANDOM» :os«cpm»;
probably because use itself can take parameters (or adverbs), and you
don't want them to collide with the class metadata.
> 4) What are the expected rules for versioning? While the public CPAN has
> one set of versioning, other projects have weird versioning rules, with
> letters and numbers. What would work and why?
not to mention the fact that a lot of modules do things like:
$VERSION = sprintf("%d.%02d", q$Revision: 1.46 $ =~ /(\d+)\.(\d+)/);
which I think is a Good Thing, and should stay there.
> These are not fully thought through answers, but illustrate some thoughts
> or the matter.
well, I have an idea on the matter. given that class definitions are
closures to be executed by the class constructor code, there should be a
context, somewhere, that knows about the current class being
constructed. in this context (and no others, presumably), the .meta
method could be given write-access to the metadata of the class.
so, you can say:
class Dog-1.21-JRANDOM { ... }
as well as:
class Dog {
.meta.version = 1.21;
.meta.author = "JRANDOM";
# and of course...
.meta.description = "This class implements camera obscura.";
.meta.subject = <>;
.meta.language = "ja_JP";
# etc.
}
cheers,
Aldo
Re: A12: a doubt about .meta, .dispatcher and final methods
On Fri, 2004-04-23 at 17:24, Larry Wall wrote:
> [...]
>
> On the sixth hand, by that argument, since .dispatcher is aiming at
> a Class, it should be an uppercase C<>. :-)
why not wash all these hands altogether?
IDEA 1
implementing a "final" trait should be trivial enough (it just throws an
exception when, at class construction time, it sees a method that is eq
a base method marked final). so this could be something like (pretending
Object will be written in P6 rather than "gloriously grungy C code" :-):
class Object {
has MetaClass $.meta is final;
}
this would also allow the following code to not compile:
class HumanBeing {
method die is final {
$_.rest_in_peace();
}
}
class Zombie is HumanBeing {
method die {
return undef;
}
}
so long for B-series splatter movies, but hey :-)
IDEA 2
since the .meta method should be the first thing in the inheritance tree
(unless you negate somehow your inheritance from Object, but in this
case you are supposed to know what you're doing), even if you overload
it, the "correct" .meta should always be available as:
($obj.+meta)[-1]
and once we have $obj.+meth, $obj.*meth and $obh.?meth modeled after
regexp modifiers, I see no reason why we shouldn't have:
$obj.^meta
which, calling the most derived method, should always do the Right
Thing.
cheers,
Aldo
A12: on inheriting wrappers
let's suppose I want to build a class that keeps track of the objects it
creates.
let's suppose that I want this class to be the base for a variety of
classes.
let's suppose that I decide, rather than fiddling with the default
constructor, to wrap it up.
something like:
class Animal {
our @.zoo;
&new.wrap( {
my @results = call();
push(@.zoo, @results[0]);
return @results;
} );
}
class Lion is Animal { ... }
class Tiger is Animal { ... }
class Panther is Animal { ... }
my $simba = Lion.new();
my $shere_khan = Tiger.new();
my $bagheera = Panther.new();
my @all = @Animal::zoo;
# @all should contain ($simba, $shere_khan, $bagheera);
will the above code work as expected, or is there something I've
overlooked?
cheers,
Aldo
Re: A12: on inheriting wrappers
On Fri, 2004-04-30 at 16:59, Stéphane Payrard wrote:
> Perl6 seems already to have plenty of mechanisms like delegation
> to dynamically change the behavior of a class. So, probably,
> wrappers is a mechanism more adapted to extend method behavior at
> run-time by entities that don't have access to the internals of a
> class.
>
> Comments?
that's all true. I just wanted to "stress" the mechanism to understand
the various implications. and wrappers seem a good tool, anyway, to
implement something similar to Aspect Oriented Programming. but Aspects
need to be modular units, like classes or roles, so I wanted to explore
the possible interoperability of wrappers and classes. another example I
can think of:
role Logging {
POST {
foreach ( ::_.meta.getmethods() ) -> $method {
$method.wrap( {
log($somewhere, "calling $method");
call;
log($somewhere, "called $method");
} );
}
}
class Foo does Logging { ... }
does something like this make sense?
cheers,
Aldo
Re: A12: on inheriting wrappers
On Fri, 2004-04-30 at 19:01, Larry Wall wrote:
> That would almost certainly fail with an error saying that it couldn't
> find your &new subroutine. The & sigil does not imply dispatch, and
> the default .new is inherited, not autogenerated, last I checked. :-)
ouch. too true.
so I guess my Animal class should be written as:
class Animal {
our @.zoo;
method new(Class $class: *%_) {
my $self = $class.bless(0, *%_);
push(@.zoo, $self);
return $self;
}
}
but: what if Animal does inherits from something else? what I would like
to do (what I was trying to do with wrappers, that is) is to call the
inherited constructor, then do something with the returned object.
something like:
method new(Class $class: *%_) {
my $self = $class.WALK[:omit(::_)].new(*%_);
push(@.zoo, $self);
return $self;
}
this is based, of course, on the assumption that ::_ always contains
"Animal", even when building a "Lion is Animal" object.
or, if I read correctly the paragraph in "Calling Superclasses, and
Not-So-Superclasses":
Now, sometimes you want to call the net method, but you want to
change the arguments [...] If you use the call keyword in an
ordinary (nonwrapper) method, it steals the rest of the dispatch
list from the outer loop [...]
perhaps my method could be:
method new(Class $class: *%_) {
my $self = call($class, *%_);
push(@.zoo, $self);
return $self;
}
but are the arguments still passed correctly (eg. $class as the
invocant) in this case?
cheers,
Aldo
Re: Named parameters vs. slurpy hash syntax: brittle call syntax!
On Thu, 2004-05-06 at 02:36, Dov Wasserman wrote:
> After the New And Improved logError() routine is rolled out, it seems to me
> that this log statement should generate a compile-time error, since the
> named Int parameter "prio" is given a non-integer argument "HIGH". At best,
> this should be a run-time error. Either way, this confusion undermines a key
> Perl strength: ability of the user to upgrade code (without breaking it).
I strongly disagree. this fact has nothing to do with Perl itself, but
with how you decide to use it. you said "Int +$prio" because you
*wanted* code to break when "prio" is not an integer.
we have to cope with new (and greater) strenghts in Perl6, and one of
these is: "it's fine for Perl to have a type system as long as it's
optional" (cit. A6).
if you upgrade your code to do type-checking, it obviously fails when
type constraints are violated. but you don't have to. you could have
said:
sub logError($msg, +$prio = 4, *%errorInfo) {
# ...
my Str $prio_desc = getPrioDescription($prio) // $prio;
print "$prio_desc: $s.\n";
}
or even:
my Str $prio_desc = $prio;
if $prio.isa(Int) {
$prio_desc = getPrioDescription($prio);
}
cheers,
Aldo
Re: Named parameters vs. slurpy hash syntax: brittle call syntax!
On Thu, 2004-05-06 at 02:36, Dov Wasserman wrote:
> To distinguish these two cases, what if we used the := binding operator to
> bind an argument to a named parameter:
>
> logError($err_msg, prio := 3);
but how would this look like to a subroutine that is not defined to
accept a named parameter called prio? eg. if you decide to reimplement
logError to be just:
sub logError { # implicit ([EMAIL PROTECTED])
# ...
}
using a Pair, you still have someting (a Pair object) that you can
inspect, and eventually decide wether to treat as a named argument or
not. but when you use "prio := 3", what do the subroutine get? only "3"
in that position? or a Pair anyway? or it doesn't get the 3 at all?
cheers,
Aldo
simple grammar example
hello gentlemen,
I'm preparing a talk about Perl6 for the Italian Perl Workshop, and I
would like to have a slide comparing a BNF (yacc/bison) grammar to a
Perl6 one, to show how powerful in parsing/lexing Perl6 regexen are.
so I ask your assistance in helping me putting up a simple, yet
impressive enough, sample.
I've taken this bison example (an RPN calculator, stripped down version
from http://www.gnu.org/software/bison/manual/html_node/Rpcalc-Rules.html):
input:/* empty */
| input line
;
line: '\n'
| exp '\n'
;
exp: NUM
| exp exp '+'
| exp exp '-'
| exp exp '*'
| exp exp '/'
;
%%
and this is my attempt at a "port" to Perl6:
grammar RPN {
rule input { * }
rule line { ? \n }
rule exp {
[ NUM
| <'+'>
| <'-'>
| <'*'>
| <'/'>
]
}
rule NUM { \d+ } # could be more complex, I know :-)
}
if $data ~~ RPN.input { say "valid RPN data" }
am I missing something obvious here? will the above code work in Perl6?
do you have perhaps a better example, or just an idea about what to show?
cheers,
Aldo
Re: String interpolation
Larry Wall wrote:
Hmm. That makes me wonder what the slice notation for "everything" is.
maybe @foo[..] (a short form for @foo[0..Inf]) ? %foo{..} should also be
allowed, of course (which
unfortunately is not a short form for 0..Inf). or perhaps, with a slight
analogy with filesystems, @foo[*]
and %foo{*}. I was tempted to suggest yada-yada-yada (eg. @foo[...]),
but this should mean "a slice
not (yet) determined", right?
cheers,
Aldo
Re: String interpolation
Jonathan Scott Duff wrote: Surely you mean [EMAIL PROTECTED] instead of 0..Inf I think the iterator implicit in array slicing should, and could, be smart enough to return when there's nothing more to iterate. Considering the following code: @foo = (1, 2, 3); @bar = @foo[1..Inf]; @bar should contain (2, 3). the iterator could just throw an X::ENOITEM (or some such) exception after the "3", which (unless catched and rethrowed by a CATCH block, perhaps) will just terminate the iteration. furthermore, something like: @bar[1..Inf] = @foo; should not (DWIMmy) take forever, but just assign (1, 2, 3) to the second, third and fourth element in @bar. on the other hand, this contrasts with the following code: ($x, $y, $z) = (1, 2); which (in Perl5 at least) assigns undef to $z. for orthogonality's sake, the @bar[1..Inf] assignment should then produce an infinite lists of undefs, which doesn't look too practical. so maybe Inf should have a special meaning in array splicing anyway. cheers, Aldo
Re: [OT] Perl 6 Summary for 2004-10-01 through 2004-10-17
Larry Wall wrote: I suppose if I were Archimedes I'd have climbed back out and shouted "Eureka", but as far as I know Archimedes never made it to Italy, so it didn't occur to me... well, Archimedes *was* italian. for some meaning of italian, at least. he was born in Syracuse (the one in Sicily, not the one in the state of NY obviously :-). he lived and studied in Egypt, but most of his life was spent in Syracuse. granted, Sicily at that time was more a Greek region than an Italian one as it is today, but well, geographically speaking, it is in Italy. and of course, Venice was founded ~700 years after Archimedes death, so he really had no chance of falling into your same canal. anyway, Larry, I hope the water wasn't too cold :-) cheers, Aldo
parrot on the Itanium: almost there
good day by chance, I have an Itanium machine under my control. it is a (rather-old) HP i2000 Workstation with Itanium 1. this is what "cat /proc/cpuinfo" says: processor : 0 vendor : GenuineIntel arch : IA-64 family : Itanium model : 0 revision : 6 archrev: 0 features : standard cpu number : 0 cpu regs : 4 cpu MHz: 733.343996 itc MHz: 733.343996 BogoMIPS : 729.80 I have equipped it with a Debian 3.0, and this is what "uname -a" says: Linux ariete 2.4.19-itanium-smp #1 SMP Wed Oct 23 20:05:46 MDT 2002 ia64 unknown finally, this is what "perl -v" says: This is perl, v5.6.1 built for ia64-linux and what "gcc --version" says: 2.96 I'm writing all this to you because, as you can imagine, one of the first things I've done on it was to download and compile parrot :-) well, everything built fine (except for some quirks in the docs due to the fact that my perldoc insists on exiting with errorcode 1 instead of 0). I ran "make test" and the final results are: Failed Test Status Wstat Total Fail Failed List of Failed t/op/gc.t 3 768 83 37.50% 1, 3-4 t/op/stacks.t 1 256561 1.79% 6 t/op/string.t 1 256 1191 0.84% 90 t/pmc/intlist.t3 768 93 33.33% 3-4, 6 t/pmc/io.t 2 512202 10.00% 2, 8 27 subtests skipped. Failed 5/59 test scripts, 91.53% okay. 10/942 subtests failed, 98.94% okay. a complete transcript of the "make test" output is available for the interested at: http://dada.perl.it/parrot-ia64-test.txt I tried "make mops", just for fun, but it failed with: make[1]: Entering directory `/root/parrot/examples/assembly' ../../parrot -o mops.pbc mops.pasm PackFile_pack segment 'DIRECTORY' used size 166 but reported 168 make[1]: *** [mops.pbc] Error 1 make[1]: Leaving directory `/root/parrot/examples/assembly' make: *** [examples/assembly/mops.pbc] Error 2 I'm going to setup a tinderbox client on the machine. should someone need more information about the machine and/or the test environment, just ask :-) hope this helps! cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: parrot on the Itanium: almost there
Leopold Toetsch wrote: > Probably some INTVAL/opcode_t mismatch. What does > > $ cat myconfig > > yield on that machine? here is it, in all its shining gory details :-) (BTW, in the mean time I've switched to gcc 3.0, but the results seem to be absolutely the same) Summary of my parrot 0.0.11.2 configuration: configdate='Thu Oct 2 19:27:19 2003' Platform: osname=linux, archname=ia64-linux jitcapable=0, jitarchname=nojit, jitosname=nojit, jitcpuarch=i386 execcapable=0 perl=perl Compiler: cc='gcc-3.0', ccflags='-DDEBIAN -I/usr/local/include -D_LARGEFILE_SOURCE -D _FILE_OFFSET_BITS=64', Linker and Libraries: ld='cc', ldflags=' -L/usr/local/lib', cc_ldflags='', libs='-ldl -lm -lcrypt' Dynamic Linking: so='.so', ld_shared='-shared -L/usr/local/lib', ld_shared_flags='' Types: iv=long, intvalsize=8, intsize=4, opcode_t=long, opcode_t_size=8, ptrsize=8, ptr_alignment=4 byteorder=12345678, nv=double, numvalsize=8, doublesize=8 cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
[perl #24149] [PATCH] small Makefile patch (rm *.s in realclean instead of clean)
# New Ticket Created by "Aldo Calpini" # Please include the string: [perl #24149] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=24149 > make clean is currently doing an rm *.s, thus removing the asmfun.s which gets installed by Configure.pl. this means that, in order to build parrot after a make clean, you need to run Configure.pl again. this patch moves the rm *.s instruction to the (seemingly more appropriate) 'realclean' make target. cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print; -- attachment 1 -- url: http://rt.perl.org/rt2/attach/65774/49110/5adfe4/makefile.patch makefile.patch Description: makefile.patch
[perl #24205] [PATCH] removing -mno-accumulate-outgoing-args for non x86 arch
# New Ticket Created by "Aldo Calpini"
# Please include the string: [perl #24205]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=24205 >
hello,
currently Configure.pl insists on passing a
-mno-accumulate-outgoing-args option to GCC 3.x.
a trustworthy source (Nicholas :-) told me that this should only be
available on x86 and x86-64, and in fact my ia64 complains that the
option is invalid.
I've patched /config/auto/gcc.pl to check if $Config{archname} =~
/86/, and in case it doesn't, remove the offending option.
I'm not sure this is the correct approach, but it shouldn't affect
negatively other systems/versions, and for sure it works on my ia64.
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/66031/49341/fcaf5c/gcc_pl.patch
gcc_pl.patch
Description: gcc_pl.patch
pcc: the parrot C compiler (just a wrapper, don't expect big things :-)
hello,
I was trying to debug the t/src tests, and realized that doing by hand
what Parrot::Test::c_output_(is|like) does is not really easy.
I wanted to compile the source code embedded in t/src/sprintf.t (the
third test, in my case) to see exactly where and how it was failing, and
possibly have a chance to debug it.
so, I ended up looking in lib/Parrot/Test.pm and writing a simple
script which mimics what that module does (just a wrapper that calls
gcc with all the settings from Parrot::Config).
I've called it pcc, and it should reside in the root parrot directory.
the source is merely 17 lines long, so I attach it at the end of this
mail.
now, I'm able to pull out the source code from t/src/sprintf.t, save
it, let's say, in many_printfs.c and then do:
$ ./pcc many_printfs.c
$ ./many_printfs
hope this helps :-)
$ cat pcc
#!/usr/bin/perl -w
use lib 'lib';
use Parrot::Config;
my $libparrot = $PConfig{blib_lib_libparrot_a};
$libparrot =~ s/\$\(A\)/$PConfig{a}/;
my $source_f = $ARGV[0] || die "no source specified\n";
(my $obj_f = $source_f) =~ s/\.c/$PConfig{o}/ie;
(my $exe_f = $source_f) =~ s/\.c/$PConfig{exe}/ie;
my $cmd = "$PConfig{cc} $PConfig{ccflags} $PConfig{cc_debug} ".
" -I./include -c $PConfig{cc_o_out}$obj_f $source_f";
system("$cmd") && die "compile failed with exit code ".($?>>8)."\n";
$cmd = "$PConfig{link} $PConfig{linkflags} $PConfig{ld_debug} $obj_f ".
"$PConfig{ld_out}$exe_f $libparrot $PConfig{libs}";
system("$cmd") && die "link failed with exit code ".($?>>8)."\n";
__END__
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: [PS] open patches
these are the patches of mine which still show as Pending: (17405) [PATCH] correct make pdb on Win32 (24149) [PATCH] small Makefile patch (rm *.s in realclean instead of clean) (24205) [PATCH] removing -mno-accumulate-outgoing-args for non x86 arch the last one was applied by Dan, but the Status wasn't updated on RT. I can't do it myself (permission denied). cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
JIT for Win32
hello there (and especially the JIT team),
is anybody working on JIT-enabling the Win32 platform?
I've done some work on this (using MASM as an assembler
and VisualC's DUMPBIN as a disassembler instead of the
GNU as and objdump).
I have a somewhat-working Parrot/Jit/MSWin32-x86.pm that
generates a somewhat-correct jit_struct.h.
there's still nothing implemented in .jit files (only
Parrot_noop and Parrot_end in core.jit right now), so
every opcode is just a Parrot::Jit->call output.
I tested examples/assembly/fact.pasm and with the -j
option it goes as far as saying: 'fact of 0'.
it missed the constant 'is: ', because
if (s && string_length(s)) {
in core_ops.c was not true, and then it blows up on the
pasm line:
set I0,I1
which core_ops.c implements as:
interpreter->string_reg.registers[cur_opcode[1]]
= string_from_int(interpreter, cur_opcode[2]);
the problem is that when it comes to this instruction,
cur_opcode[1] contains a totally unrelated value
(-41485056, or 0xfd86fd00), but cur_opcode[2] contains
0 as it should.
I have no idea why cur_opcode is broken. the jitted code
actually looks like this:
55 pushebp
8B E5mov esp,ebp
68 30 3C 2F 00 push2F3C30h
68 C0 EA 2F 00 push2FEAC0h
E8 7F 3F 10 00 callParrot_set_i_ic (00402da9)
83 C4 08 add esp,8
68 30 3C 2F 00 push2F3C30h
68 CC EA 2F 00 push2FEACCh
E8 7D 34 10 00 callParrot_print_sc (004022b9)
83 C4 08 add esp,8
68 30 3C 2F 00 push2F3C30h
68 D4 EA 2F 00 push2FEAD4h
E8 8E 33 10 00 callParrot_print_i (004021dc)
83 C4 08 add esp,8
68 30 3C 2F 00 push2F3C30h
68 DC EA 2F 00 push2FEADCh
E8 59 34 10 00 callParrot_print_sc (004022b9)
83 C4 08 add esp,8
68 30 3C 2F 00 push2F3C30h
68 E4 EA 2F 00 push2FEAE4h
E8 1D 3F 10 00 callParrot_set_i_i (00402d8f)
83 C4 08 add esp,8
which seems fine to me. so, I'm lost :-(
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
JIT for Win32
hello there (and especially the JIT team),
is anybody working on JIT-enabling the Win32 platform?
I've done some work on this (using MASM as an assembler
and VisualC's DUMPBIN as a disassembler instead of the
GNU as and objdump).
I have a somewhat-working Parrot/Jit/MSWin32-x86.pm that
generates a somewhat-correct jit_struct.h.
there's still nothing implemented in .jit files (only
Parrot_noop and Parrot_end in core.jit right now), so
every opcode is just a Parrot::Jit->call output.
I tested examples/assembly/fact.pasm and with the -j
option it goes as far as saying: 'fact of 0'.
it missed the constant 'is: ', because
if (s && string_length(s)) {
in core_ops.c was not true, and then it blows up on the
pasm line:
set I0,I1
which core_ops.c implements as:
interpreter->string_reg.registers[cur_opcode[1]]
= string_from_int(interpreter, cur_opcode[2]);
the problem is that when it comes to this instruction,
cur_opcode[1] contains a totally unrelated value
(-41485056, or 0xfd86fd00), but cur_opcode[2] contains
0 as it should.
I have no idea why my opcodes are broken. the jitted code
actually looks like this:
55 pushebp
8B E5mov esp,ebp
68 30 3C 2F 00 push2F3C30h
68 C0 EA 2F 00 push2FEAC0h
E8 7F 3F 10 00 callParrot_set_i_ic (00402da9)
83 C4 08 add esp,8
68 30 3C 2F 00 push2F3C30h
68 CC EA 2F 00 push2FEACCh
E8 7D 34 10 00 callParrot_print_sc (004022b9)
83 C4 08 add esp,8
68 30 3C 2F 00 push2F3C30h
68 D4 EA 2F 00 push2FEAD4h
E8 8E 33 10 00 callParrot_print_i (004021dc)
83 C4 08 add esp,8
68 30 3C 2F 00 push2F3C30h
68 DC EA 2F 00 push2FEADCh
E8 59 34 10 00 callParrot_print_sc (004022b9)
83 C4 08 add esp,8
68 30 3C 2F 00 push2F3C30h
68 E4 EA 2F 00 push2FEAE4h
E8 1D 3F 10 00 callParrot_set_i_i (00402d8f)
83 C4 08 add esp,8
which seems fine to me. so, I'm lost :-(
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: JIT for Win32
Daniel Grunblatt wrote: > > is anybody working on JIT-enabling the Win32 platform? > > Yes, the new JIT will work (actually, it works) on Windows, probably you > didn't read the TODO, says '(currently on hold, waiting for JIT v2)', so, > as soon as the the code is in you will be able to use the JIT on windows > and help us enhancing it :) oh well... stupid me, I worked on the parrot-0.0.5 distro, just forgot about peeking at the CVS repository :-) it was really nice to work on it anyway. I have learned alot of things, and would like to suggest an 'enhancement' to Configure.pl. if the compiler is 'cl' (that is, Visual C++), and you invoke Configure.pl with --debugging, it should add '-DDEBUG -D_DEBUG -FAcs -Fa -FR' to CFLAGS in the Makefile. I've found that with these switches debugging in Visual C++ is far more pleasant. also, to inspect core_ops.c in the debugger (instead of the not-so-helpful core.ops), I had to comment all the #line directives in core_ops.c. what is your opinion about these changes? if you think they're worthy, I can submit a patch. cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: [netlabs #596] .XS build process needs to be more portable
Jeffrey Goff (via RT) wrote:
> I've just patched lib/Parrot/Makefile.PL to check for a Win32 platform,
> and if so, use .obj for the default object extension. However I did it
> simply by checking $^O for 'Win'. This is probably not as portable as it
> could be, but a quick look through ExtUtils::MakeMaker didn't reveal a
> variable that could be used for determining the proper extension.
I guess this is not portable, in fact. the Cygwin build under Win32 uses
.o extension as Unix does. but this seems to give a reasonable answer:
# perl -MConfig -e "print $Config{_o};"
.obj
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
recursion in pasm (and timings)
hi there, the Examples page on www.parrotcode.org states this about subroutines: The first five registers (I0-I4, S0-S4, P0-P4, N0-N4) are scratch and do not have to be preserved by the callee. this seems to be false for *recursive* subroutines. this is my PASM code fibo.pasm (it calculates the fibonacci number of 32): set I0, 32 bsr FIBO print I0 print "\n" end FIBO: lt I0, 2, FIBO_ONE set I1, I0 set I2, I1 dec I2, 2 set I0, I2 save I1 save I2 save I3 bsr FIBO restore I3 restore I2 restore I1 set I1, I0 inc I2 set I0, I2 save I1 save I2 save I3 bsr FIBO restore I3 restore I2 restore I1 add I0, I0, I1 branch FIBO_END FIBO_ONE: set I0, 1 FIBO_END: ret for this code to work correctly, I need to save and restore I1, I2, I3 on each recursive call. am I missing something or is just something that needs to be documented? and now for timings: I tested the new parrot (checked out some minutes ago) with JIT v2 enabled and these are the results: CPUMEM parrot fibo.pbc8.74736 parrot -j fibo.pbc 6.13772 just for reference, these are the times from other languages: CPUMEM Visual C++ (6.0) 0.13452 gcc (2.95.3) 0.20 1344 C# (7.00.9466) 0.24 3888 java (1.4.0-b92) 0.58 4972 python (2.1.1)14.72 2128 perl (5.6.1) 21.89 1416 ruby (1.6.5) 29.71 1912 note that comparison with parrot is not really fair because all the other programs accept the number (32 in our case) from the command line. cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: recursion in pasm (and timings)
Aldo Calpini wrote: > and now for timings: [...] em... forgot to include the platform details: OS: Windows 2000 Advanced Server + Cygwin 1.3.10 CPU: AMD K7 550MHz RAM: 256 MB cheers, Aldo __END__ $_=q,just perl,,s, , another ,,s,$, hacker,,print;
[PATCH] new i386/core.jit entries
hello,
I've added the following new ops to i386/core.jit:
inc_i
dec_i
inc_i_ic
dec_i_ic
lt_i_ic_ic
lt_i_i_ic
gt_i_ic_ic
gt_i_i_ic
ge_i_ic_ic
ge_i_i_ic
le_i_ic_ic
le_i_i_ic
eq_i_ic_ic
eq_i_i_ic
also fixed buggy definitions for emitm_cmpl_r_m and emitm_cmpl_m_r
in i386/jit_emit.h.
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
Index: core.jit
===
RCS file: /cvs/public/parrot/jit/i386/core.jit,v
retrieving revision 1.17
diff -c -b -r1.17 core.jit
*** core.jit 20 May 2002 05:32:59 - 1.17
--- core.jit 22 May 2002 10:34:48 -
***
*** 74,79
--- 74,163
emit_jump(jit_info, *INT_CONST[1]);
}
+ Parrot_inc_i {
+ emitm_movl_m_r(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
&INT_REG[1]);
+ emitm_addl_i_r(NATIVECODE, 1, emit_EAX);
+ emitm_movl_r_m(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
&INT_REG[1])
+ }
+
+ Parrot_dec_i {
+ emitm_movl_m_r(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
&INT_REG[1]);
+ emitm_subl_i_r(NATIVECODE, 1, emit_EAX);
+ emitm_movl_r_m(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
&INT_REG[1])
+ }
+
+ Parrot_inc_i_ic {
+ emitm_movl_m_r(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
&INT_REG[1]);
+ emitm_addl_i_r(NATIVECODE, *INT_CONST[2], emit_EAX);
+ emitm_movl_r_m(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
&INT_REG[1])
+ }
+
+ Parrot_dec_i_ic {
+ emitm_movl_m_r(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
&INT_REG[1]);
+ emitm_subl_i_r(NATIVECODE, *INT_CONST[2], emit_EAX);
+ emitm_movl_r_m(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
&INT_REG[1])
+ }
+
+ Parrot_lt_i_ic_ic {
+ emitm_movl_m_r(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
&INT_REG[1]);
+ emitm_cmpl_i_r(NATIVECODE, *INT_CONST[2], emit_EAX);
+ emit_jcc(jit_info, emitm_jl, *INT_CONST[3]);
+ }
+
+ Parrot_lt_i_i_ic {
+ emitm_movl_m_r(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
&INT_REG[1]);
+ emitm_cmpl_r_m(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
&INT_REG[2]);
+ emit_jcc(jit_info, emitm_jl, *INT_CONST[3]);
+ }
+
+ Parrot_gt_i_ic_ic {
+ emitm_movl_m_r(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
&INT_REG[1]);
+ emitm_cmpl_i_r(NATIVECODE, *INT_CONST[2], emit_EAX);
+ emit_jcc(jit_info, emitm_jg, *INT_CONST[3]);
+ }
+
+ Parrot_gt_i_i_ic {
+ emitm_movl_m_r(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
&INT_REG[1]);
+ emitm_cmpl_r_m(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
&INT_REG[2]);
+ emit_jcc(jit_info, emitm_jg, *INT_CONST[3]);
+ }
+
+ Parrot_ge_i_ic_ic {
+ emitm_movl_m_r(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
&INT_REG[1]);
+ emitm_cmpl_i_r(NATIVECODE, *INT_CONST[2], emit_EAX);
+ emit_jcc(jit_info, emitm_jnl, *INT_CONST[3]);
+ }
+
+ Parrot_ge_i_i_ic {
+ emitm_movl_m_r(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
&INT_REG[1]);
+ emitm_cmpl_r_m(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
&INT_REG[2]);
+ emit_jcc(jit_info, emitm_jnl, *INT_CONST[3]);
+ }
+
+ Parrot_le_i_ic_ic {
+ emitm_movl_m_r(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
&INT_REG[1]);
+ emitm_cmpl_i_r(NATIVECODE, *INT_CONST[2], emit_EAX);
+ emit_jcc(jit_info, emitm_jle, *INT_CONST[3]);
+ }
+
+ Parrot_le_i_i_ic {
+ emitm_movl_m_r(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
&INT_REG[1]);
+ emitm_cmpl_r_m(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
&INT_REG[2]);
+ emit_jcc(jit_info, emitm_jle, *INT_CONST[3]);
+ }
+
+ Parrot_eq_i_ic_ic {
+ emitm_movl_m_r(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
&INT_REG[1]);
+ emitm_cmpl_i_r(NATIVECODE, *INT_CONST[2], emit_EAX);
+ emit_jcc(jit_info, emitm_je, *INT_CONST[3]);
+ }
+
+ Parrot_eq_i_i_ic {
+ emitm_movl_m_r(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
&INT_REG[1]);
+ emitm_cmpl_r_m(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
&INT_REG[2]);
+ emit_jcc(jit_info, emitm_je, *INT_CONST[3]);
+ }
+
/*
* Local variables:
* c-indentation-style: bsd
Index: jit_emit.h
===
RCS file: /cvs/public/parrot/jit/i386/jit_emit.h,v
retrieving revision 1.1
diff -c -b -r1.1 jit_emit.h
*** jit_emit.h 20 May 2002 05:32:59 - 1.1
--- jit_emit.h 22 May 2002 10:34:49 -
***
*** 393,400
/* Integer comparisions */
#define emitm_cmpl_r_r(pc, reg1, reg2) emitm_alul_r_r(pc, 0x39, reg1,
reg2)
! #define emitm_cmpl_r_m(pc, reg, b, i, s, d) emitm_alul_r_m(pc, 0x3b, reg1,
reg2, b, i, s, d)
! #define emitm_cmpl_m_r(pc, reg, b, i, s, d) emitm_alul_r_m(pc, 0x39, reg1,
reg2, b, i, s, d)
#define emitm_cmpl_i_r(pc, imm, reg) emitm_alul_i_r(pc, 0x81, emit_b111,
imm, reg)
--- 393,4
JIT ideas
hello people,
I've implemented some print opcodes in JIT (for i386), but I would
like to know your opinion about these before submitting a patch.
in reality, there isn't a big performance boost, because I'm just
calling printf as the C opcode does. it just saves some
push/pop/call/ret instructions. the advantage is that such hack is
portable across platform. implementing a more low-level print
mechanism (involving system calls probably) would require several
#ifdef..#endif, I suppose.
anyway, this implements a new function in jit_emit.h which makes
a call to a C function (an absolute address, that is). this is the
function I've added to jit_emit.h:
void emit_call_abs(Parrot_jit_info *jit_info,
long absaddr, int putback)
{
Parrot_jit_newfixup(jit_info);
jit_info->fixups->type = JIT_X86CALL;
jit_info->fixups->param.fptr = (void (*)(void)) absaddr;
emitm_calll(jit_info->native_ptr, 0xdeafc0de);
emitm_addl_i_r(jit_info->native_ptr, putback, emit_ESP);
}
this is very similar to Parrot_jit_normal_op, except that the
address is stored 'as it is' and the bytes to be added to ESP are
variable.
and this is how print_ic is implemented in core.jit:
Parrot_print_ic {
emitm_pushl_i(NATIVECODE, *INT_CONST[1]);
emitm_pushl_i(NATIVECODE, (long) INTVAL_FMT);
emit_call_abs(jit_info, (long) printf, 8);
}
print_nc looks like this (I needed to define a private long because
simply saying (&NUM_CONST[1])+4 doesn't work):
Parrot_print_nc {
long mydouble = (long) &NUM_CONST[1];
NATIVECODE = emit_pushl_m(NATIVECODE, emit_None, emit_None,
emit_None, mydouble+4);
NATIVECODE = emit_pushl_m(NATIVECODE, emit_None, emit_None,
emit_None, mydouble);
emitm_pushl_i(NATIVECODE, (long) FLOATVAL_FMT);
emit_call_abs(jit_info, (long) printf, 12);
}
also print_sc is similar, except that there isn't a STRINGVAL_FMT
defined in config.h:
Parrot_print_sc {
NATIVECODE = emit_pushl_m(NATIVECODE, emit_None, emit_None,
emit_None, (long) &STRING_CONST[1]->bufstart);
emitm_pushl_i(NATIVECODE, (long) "%s");
emit_call_abs(jit_info, (long) printf, 8);
}
another little thing I've done, but I'm not sure if there's need
for this, is having added these lines to jit.c in the build_asm
routine, just before returning:
if (Interp_flags_TEST(interpreter, PARROT_DEBUG_FLAG)) {
fprintf(stderr, "*** Parrot VM: JITted code at 0x%08x. ***\n",
jit_info.arena_start);
}
this way when I start 'parrot -j -d something' it tells me where
to find the JIT, and I can goto there directly in the debugger.
it's really a time saver for me.
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
Re: JIT ideas
Daniel Grunblatt wrote:
> Don't implement any print op yet, if I didn't understood wrong they are
> going to be updated to use the IO system.
ok, I draw back them then.
but I found another use for the emit_call_abs() function to implement some
string stuff in JIT. as I already said, the speed increase isn't at all
dramatic, but OTOH I have no idea how to do complicate stuff like allocating
memory natively in asm. these are the string ops that I've implemented in
JIT:
Parrot_set_s_s {
emitm_movl_m_r(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
(long) &STRING_REG[2]);
emitm_movl_r_m(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
(long) &STRING_REG[1]);
}
Parrot_set_s_sc {
NATIVECODE = emit_pushl_m(NATIVECODE, emit_None, emit_None, emit_None,
(long) &STRING_CONST[2]);
emitm_pushl_i(NATIVECODE, (long) interpreter);
emit_call_abs(jit_info, (long) string_copy, 8);
emitm_movl_r_m(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
(long) &STRING_REG[1]);
}
Parrot_concat_s_s {
emitm_pushl_i(NATIVECODE, 1);
NATIVECODE = emit_pushl_m(NATIVECODE, emit_None, emit_None, emit_None,
(long) &STRING_REG[2]);
NATIVECODE = emit_pushl_m(NATIVECODE, emit_None, emit_None, emit_None,
(long) &STRING_REG[1]);
emitm_pushl_i(NATIVECODE, (long) interpreter);
emit_call_abs(jit_info, (long) string_concat, 16);
emitm_movl_r_m(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
(long) &STRING_REG[1]);
}
Parrot_concat_s_sc {
emitm_pushl_i(NATIVECODE, 1);
NATIVECODE = emit_pushl_m(NATIVECODE, emit_None, emit_None,
emit_None,
(long) &STRING_CONST[2]);
NATIVECODE = emit_pushl_m(NATIVECODE, emit_None, emit_None,
emit_None,
(long) &STRING_REG[1]);
emitm_pushl_i(NATIVECODE, (long) interpreter);
emit_call_abs(jit_info, (long) string_concat, 16);
emitm_movl_r_m(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
(long) &STRING_REG[1]);
}
Parrot_concat_s_s_s {
emitm_pushl_i(NATIVECODE, 1);
NATIVECODE = emit_pushl_m(NATIVECODE, emit_None, emit_None, emit_None,
(long) &STRING_REG[3]);
NATIVECODE = emit_pushl_m(NATIVECODE, emit_None, emit_None, emit_None,
(long) &STRING_REG[2]);
emitm_pushl_i(NATIVECODE, (long) interpreter);
emit_call_abs(jit_info, (long) string_concat, 16);
emitm_movl_r_m(NATIVECODE, emit_EAX, emit_None, emit_None, emit_None,
(long) &STRING_REG[1]);
}
I haven't made extensive testing, but it seems there's a gain of about 10
generations per second with the lifetest. if these changes are welcome, I
will submit a (hopefully proper ;-) patch including other string stuff too.
> The -d flag will be use for the parrot debugger, Can't you stop your
> debugger at runops_jit?
well, not so easily with MSVC, but maybe it's just me (I haven't much
experience with the Visual Studio stuff).
I can't get MSVC to attach the parrot process (even with the -. option), so
the only chance I have to debug it is to press 'Cancel' when the program
blows up...
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
