RE: Key stuff for aggregates
Dan Sugalski: # 'Kay, here's the preliminary assembly-level docs for keys, # which is how # we're going to be accessing entries in aggregates. I'm probably just inexperienced and idiotic, but what's wrong with simple 'get_from_aggregate target, aggregate, key' and maybe 'get_list_from_aggregate target_list, aggregate, key_list'? (Obviously we'd shorten the names, but you get the idea.) target would be set to the actual element, not just a copy of it, so setting that would set the original. Individual aggregate types could decide for themselves what to do about currently non-existent keys. --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 Nothing important happened today. --George III of England's diary entry for 4-Jul-1776
Re: FP constants
On Tue, 4 Dec 2001, Dan Sugalski wrote: Q: What about endianness? A: Native endianness. Byteswapping's easy enough. Where in the packfile does it define the native endinaness of floats? (Note native endianess has to include wheather the sign is the MSB or the LSB, and the endianness of the exponential and fractional part.) BTW, for the record, this is IEEE 754-1985 (AKA 754-1990) details at http://grouper.ieee.org/groups/754/ A summary is at http://research.microsoft.com/~hollasch/cgindex/coding/ieeefloat.html, since this is a nonfree standard. (God, I hate them.) -=- ames Mastros -- In the case of alchemy v chemistry the chemists know whether it will probably go bang before they try it (and the chemical engineers still duck anyway). -=- Alan Cox
Re: Key stuff for aggregates
On Wed, Dec 05, 2001 at 12:18:53AM -0800, Brent Dax wrote: I'm probably just inexperienced and idiotic, but what's wrong with simple 'get_from_aggregate target, aggregate, key' and maybe 'get_list_from_aggregate target_list, aggregate, key_list'? (Obviously we'd shorten the names, but you get the idea.) target would be set to the actual element, not just a copy of it, so setting that would set the original. This is not the whole picture as the elements of an aggregate do not always have associated vtables to compute with. Consider an array of native integers (or native doubles). If you 'get' an lvalue from it, you won't know the underlying type, so computing with it is messy unless you wrap the lvalue up in some type of reference PMC. Creating one to access every element of an array will create lots of extraneous temporaries. Using the aggregate's vtable is another way of getting the job done that avoids all the extra reference PMCs. However, references will have to be supported. -- Jason
Re: Parrot FAQ
At 06:29 PM 12/4/2001 -0800, Steve Fink wrote: On Tue, Dec 04, 2001 at 04:11:58PM -0500, Dan Sugalski wrote: Seriously, there are real answers to a whole lot of design questions. Ask 'em and I'll get FAQable answers to 'em once and for all. Whee! Ok. Some of these are probably duplicates, and some inappropriate for a Parrot FAQ, but: Q: Will perl6 support the same regexes as perl5? A: Yup. At least everything we understand... Q: Larry said _what_? What does that mean? A: Got me. Context? Q: But won't all those opcodes require a huge amount of dispatch time and slow regexes down to a crawl? A: Ah, that's what you mean! Well, the answer is maybe. Right now parrot's opcode dispatch is darned fast. (The Perl 5 RE engine is a mini-bytcode engine itself, FWIW, albeit a specialized one, so we're not paying a cost that it isn't, though our cost might be higher. We'll see) Q: Ok, but what if they're a quarter the speed of perl5's? A: Then we toss the idea as interesting, but bad and go to Plan B. Q: What about incremental matching? A: What about it? Q: What platforms will Parrot support, initially and eventually? A: Initially the list is: Solaris (Sparc), OpenVMS (Alpha), CygWin, Windows 95/NT, Linux (x86), Tru64, FreeBSD (x86) as guaranteed. Odds are anything Unixish will work (builds on AIX, MacOS X, and HP/UX) Eventually the list is everything anyone's got sufficient patches to support. Q: What degree of Unicode support is Parrot aiming for? A: Complete. Q: What does that mean? A: Means that if the Unicode standard says something about it, we support it. Q: When'll Parrot be done? A: It's software. It's *never* done. :) Q: Any plans for continuations? Coroutines? A: Maybe, and yes. (continuations are contingent on Dan understanding them, and he doesn't. Dunno why, might be because he writes about himself in the third person, the arrogant bastard) Q: This whole project is crap. A total waste of time. I think you're ugly, too. You should be using X as your VM. A: Yeah, well you're ugly and your mother dresses you funny. Nyah! And X is utter crap as a VM. Q: What previous discussions? Are there archive links I can use? A: Archives live at http://archive.develooper.com/perl6-internals%40perl.org/ though I see there's not much search functionality. Q: Why aren't you reusing big gobs of the perl5 code? A: Licensing. As soon as we sort that out, we will. Q: Fine. But surely some pieces could be reused? A: Not until the licensing's sorted out. Then it depends on whether we can. Q: Oh. Why are licenses a problem? Doesn't the AL allow this sort of thing? A: IANAL, and I don't play one on TV, but snagging code under a licensing scheme does sort of obligate you to follow that license. Since we don't have one for Parrot source quite yet, I'd rather not. Q: Doesn't perl5 already generate VM opcodes? Couldn't you write a translation layer to graft a perl5 frontend to a Parrot backend? A: Yes, though there are still issues with anything that calls the lexer at runtime. (Eval/do/require) We'll probably do it, though. Q: Why do people yell at me when I send patches using // for comments? They're ANSI C, you know. A: C99, IIRC. I don't think original ANSI C accepted them, and that's all we're requiring at the moment. Q: Can I use gcc extensions? A: Not in generic code, no. In special tuned for speed optional sections, sure. The core dispatch loop can already use computed gotos, and that's about as GCC-specific as you can get. Q: What API will extension writers write to? A: Parrot's. Q: How will garbage collection interact with extensions? A: There'll be some caveats, but reasonably well. For the most part extension writers won't have to worry much about it, and we'll document the spots where they will. Parrot's potentially got a copying GC system, which means that tracked buffers may move, but you'll know which calls may allocate memory (and thus potentially cause movement). There'll be easy access to the GC controls so you can turn GC off if you need to. Q: How will finalization [or whatever the right word is] interact with extensions? A: You mean object destruction? Correctly. If you allocate a PMC within an extension subroutine, that PMC will be considered active at least until the end of the sub. Q: What's the difference between the previous two questions? A: The first deals with potentially reclaiming or moving allocated memory, the second with figuring out whether a variable is dead or not. Q: What will Parrot's IO subsystem look like? A: VMS' QIO system. Sorta. Q: In what format will Parrot files be stored? A: I presume you mean data files. They won't be anything special--plain text files, or DB/DBM/[SGN]DBM, or whatever. If you mean parrot bytecode files, they'll be in our native format. Q: Why aren't you using something like ELF as the on-disk binary format? A: Portability. Q: Who has commit privileges? Who's responsible for what?
Parrot optimizer
Since PMCs are done, languages should start to come out again. Every good code generator needs a backend, and here's a first stab at an optimizer for Parrot: http://216.254.0.2/~jgoff/Files/optimizer.perl It takes a file of Parrot code post-macro-expansion, although it's internally just a module that silly-walks an array of lines with a small wrapper. -- Jeff [EMAIL PROTECTED]
Re: Parrot FAQ
A: VMS' QIO system. Sorta. Its been years since I worked on VMS. QIO is sorta async-IO, no? Can someone point me to some starting material for QIO and/or unimplemented wants/wishes for Parrot's IO sybsys? I might like to wade in in this area. I'll also start looking thru the archive. Melvin Smith
Various pre-0.0.3 updates.
I've finally got around to adding perlundef.pmc, which means that the classes/Makefile has changed; this means you'll all - and tinderbox people especially - have to rerun Configure. I suppose someone should add tests for perlundef.pmc, but I hate writing tests. :) (Especially if I think they might fail. ;) Since 0.0.3 is exceptionally imminent, can I have a roll-call of systems which are working and not working? The other change I made today was to make the assembler understand new P0, PerlInt new P1, PerlString and so on. (I've also updated the tests to reflect this.) I'm marginally happier about documentation now that I've seen the automatically generated stuff, but I want four more documents to go into Parrot before 0.0.3: basic introduction and roadmap to documentation, the (rest of the) vtables docs, some documentation on the bytecode format, and a basic guide to programming Parrot, getting stuff compiled, etc. The last one (parrotintro.pod) can be cobbled together from my perl.com article and some stuff from parrotcode.org - I'll do that tonight. If anyone wants to write the bytecode documentation and the introduction/roadmap, I'd be thrilled. -- In a sense Christianity is like Jazz - if you need to ask the questions you won't understand the answers. - Bob Billing
Re: Parrot FAQ
At 12:29 PM 12/5/2001 -0500, Melvin Smith wrote: A: VMS' QIO system. Sorta. Its been years since I worked on VMS. QIO is sorta async-IO, no? Completely async, yep, as are many of VMS' system calls. Can someone point me to some starting material for QIO and/or unimplemented wants/wishes for Parrot's IO sybsys? I might like to wade in in this area. I'll also start looking thru the archive. That's what we've got at the moment. There's not been much heavy thought pointed at I/O yet. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Key stuff for aggregates
At 12:18 AM 12/5/2001 -0800, Brent Dax wrote: Dan Sugalski: # 'Kay, here's the preliminary assembly-level docs for keys, # which is how # we're going to be accessing entries in aggregates. I'm probably just inexperienced and idiotic, but what's wrong with simple 'get_from_aggregate target, aggregate, key' and maybe 'get_list_from_aggregate target_list, aggregate, key_list'? That falls down for aggregates that don't hold PMCs. Packed integer/float/string arrays, or 'real' multidimensional arrays where you don't fully qualify things. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Key stuff for aggregates
At 10:28 AM 12/5/2001 -0500, Jason Gloudon wrote: Using the aggregate's vtable is another way of getting the job done that avoids all the extra reference PMCs. However, references will have to be supported. References are interesting. I'm currently thinking that: *) PMCs should have a get_reference vtable entry *) Accessing a reference should be just like accessing the referent. (i.e. you pass in the same key stuff and the reference vtable does the indirect lookup for you) *) Some references will need to be 'smart', so if you do: $foo = \@bar[4]; and @bar's a packed array, $foo's actually a fancy ref that knows it points to @bar[4] and calls @bar's vtables when you access it. Or something like that. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Various pre-0.0.3 updates.
On Wed, 5 Dec 2001, Simon Cozens wrote: Since 0.0.3 is exceptionally imminent, can I have a roll-call of systems which are working and not working? FreeBSD 4.4 / gcc Irix6.5 / MIPSPro Alex
Re: Various pre-0.0.3 updates.
At 05:42 PM 12/5/2001 +, Simon Cozens wrote: and tinderbox people especially - have to rerun Configure. Doing a make clean looks to be required first to get tinderbox checkouts happy again. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Various pre-0.0.3 updates.
At 05:57 PM 12/5/2001 +, Alex Gough wrote: On Wed, 5 Dec 2001, Simon Cozens wrote: Since 0.0.3 is exceptionally imminent, can I have a roll-call of systems which are working and not working? FreeBSD 4.4 / gcc Irix6.5 / MIPSPro Would those be working or not working? :) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Various pre-0.0.3 updates.
On Wed, 5 Dec 2001, Simon Cozens wrote: I've finally got around to adding perlundef.pmc, which means that the classes/Makefile has changed; this means you'll all - and tinderbox people especially - have to rerun Configure. I suppose someone should add tests for perlundef.pmc, but I hate writing tests. :) (Especially if I think they might fail. ;) Since 0.0.3 is exceptionally imminent, can I have a roll-call of systems which are working and not working? OpenBSD 3.0/gcc working.
Re: Key stuff for aggregates
At 12:52 AM 12/5/2001 -0500, Jeff G wrote: The fact that the S registers are in fact generic struct registers is not evident from outside the internal code. For those of us implementing instructions, it might be useful to explicitly cast values like $1 to the correct type, in order to make sure we recognize this. Good point. I'll kick into this after 0.03's out. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Re: Various pre-0.0.3 updates.
Oh, you technical people: Dan Sugalski [EMAIL PROTECTED] wrote: FreeBSD 4.4 / gcc Irix6.5 / MIPSPro Would those be working or not working? :) The answer is, obviously, Yes. Now get back to work. Whoops--that was someone talking to me! John A
Re: Licensing and source. READ ME, DAMMIT!
At 04:25 AM 12/5/2001 -0500, James Mastros wrote: On Tue, 4 Dec 2001, Dan Sugalski wrote: This also means no writing your own license terms for code you submit. (Licensed under the same terms as perl counts as writing your own...) Umm, AFACS (Though AINAL, and ISGCBAP (I should get caught by the acronym police) but Under the same terms as _parrot_ should be fine. If it's in the parrot distribution it ought not even *have* licensing terms attached to it. That's what the package license is for... Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot FAQ
At 03:38 AM 12/5/2001 +0100, Bart Lateur wrote: On Tue, 04 Dec 2001 15:57:56 -0500, Dan Sugalski wrote: Q: Don't you know that stack machines are the way to go in software? A: No, in fact, I don't. Q: But look at all the successful stack-based VMs! A: Like what? There's just the JVM. Q: What about all the others? A: *What* others? That's it, unless you count perl, python, or ruby. I thought Pascal's (ancient) p-code was a stack VM... Yup, some web pages that I can find in a hurry, confirm that. Right, but back then they called 'em p-code interpreter which was far less pretentious. :) Besides, the only p-code machine I could think of was UCSD Pascal running on the Apple IIs, and that seemed a bit old to reference. The Zork interpreter might be stack based, thinking about it, but it was hardly geared for speed, so I don't know that it'd count if it was. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot FAQ
On Wed, 5 Dec 2001, Dan Sugalski wrote: The Zork interpreter might be stack based, thinking about it, but it was hardly geared for speed, so I don't know that it'd count if it was. FWIW, there are many MUDs and MUCKs out there (multiplayer text-based role-playing gmaes for those not in the know) that use a variation on FORTH as their programming language, which is purely stack-based IIRC. - D [EMAIL PROTECTED]
Re: Parrot FAQ
At 12:36 PM 12/5/2001 -0600, David M. Lloyd wrote: On Wed, 5 Dec 2001, Dan Sugalski wrote: The Zork interpreter might be stack based, thinking about it, but it was hardly geared for speed, so I don't know that it'd count if it was. FWIW, there are many MUDs and MUCKs out there (multiplayer text-based role-playing gmaes for those not in the know) that use a variation on FORTH as their programming language, which is purely stack-based IIRC. Right, but FORTH's not an interpreted language, generally speaking. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Parrot FAQ
From: Dan Sugalski [mailto:[EMAIL PROTECTED]] At 12:29 PM 12/5/2001 -0500, Melvin Smith wrote: A: VMS' QIO system. Sorta. Its been years since I worked on VMS. QIO is sorta async-IO, no? Completely async, yep, as are many of VMS' system calls. Can someone point me to some starting material for QIO and/or unimplemented wants/wishes for Parrot's IO sybsys? I might like to wade in in this area. I'll also start looking thru the archive. That's what we've got at the moment. There's not been much heavy thought pointed at I/O yet. What about Nick Ing-Simmons work on PerlIO? Or Nick himself for that matter? His last post was sometime back in September. I remember reading that ParrotIO was going to be a prototype for PerlIO. I ask because I also remember Guido being particularly interested in Python having access to ParrotIO/QIO/PerlIO or whatever it ends up being. Q0: Where can I find this FAQ? (Answer always to be present in any mention however indirect of the Parrot FAQ) A0: http://www.panix.com/~ziggy/parrot.html Q: What's the difference between ParrotIO/QIO and PerlIO? (Or Where does the former leave off and the latter begin?) A: ??? Q: Where can I find out more about ParrotIO (QIO)? A: http:[EMAIL PROTECTED]/msg02116.html (It doesn't look like this ever made it into the PDD section) Q: Where can I find out more about PerlIO? http://pxr.perl.org/source/pod/perliol.pod
Re: Parrot FAQ
On Wed, 05 Dec 2001 13:32:32 -0500, Dan Sugalski wrote: Right, but FORTH's not an interpreted language, generally speaking. The old FORTH's in the 80's worked pretty much like the p-copde interpreter. Nowadays, FORTH compilers are really optimizing compilers. There are excellent commercial offerings, like VFX from MPE (MPE's Stephen Pelc showed some examples in comp.lang.forth of what machine code got generated from some FORTH code, and it was really cool -- but I can't find it back with groups.google.com, as Stephen Pelc advertises for VFX in every single post. I did manage to find something, see link below), and some less ambitious free FORTHS, like iFORTH (if I'm not mistaking) and BigFORTH. The latter has a really simple optimizer consisting of 3 screens (1 screen = 1k) of source code. http://groups.google.com/groups?selm=3C0BAB3E.BD54B0E2%40gmx.de http://groups.google.com/groups?selm=MPLT160213F08E%40mpeltd.demon.co.uk -- Bart.
Re: Parrot FAQ
On Wed, Dec 05, 2001 at 01:32:32PM -0500, Dan Sugalski wrote: Right, but FORTH's not an interpreted language, generally speaking. No, but PostScript is. :-) (...as if that wasn't completely obvious...) Z.
Re: Parrot FAQ
On Wed, Dec 05, 2001 at 11:02:34AM -0500, Dan Sugalski wrote: At 06:29 PM 12/4/2001 -0800, Steve Fink wrote: Q: What about incremental matching? A: What about it? Is there any plan to support nonbuffered matching, as in, I have a socket connection open that I want to scan for some pattern, but the socket is never going to return an EOF. Example: NONBLOCKING_SOCKET =~ /(.*?)/ I read 1MB out of the socket containing x... and then the socket stops producing data. I want to do a select(), or something else, and then go back to continuing the match, and I want the whole match to end up in $1. More simply, say you're just reading a huge file 8KB at a time, and you want to match .*? and be assured you won't miss a match because it happens to cross over an 8KB boundary. I believe there was some hot discussion on this in the perl6 RFCs. If Parrot supports coroutines, it could be hooked into that. But the RE engine might also need to say okay, nothing before byte 13231 is going to match, so you can throw it out of memory if you want. Helps with HUGEFILE =~ /.../; Probably the answer for the FAQ is dunno, depends on the mental health of whoever implements the final RE engine. Q: What degree of Unicode support is Parrot aiming for? A: Complete. Q: What does that mean? A: Means that if the Unicode standard says something about it, we support it. I know nothing about Unicode, but I thought there were levels piled upon levels of what could be done with a Unicode implementation, and nobody has ever managed to implement all of it. And aren't there choices about how to do some things? I'll shut up, because if I try to say anything like multiple code points combine to form a single whatzit, it'll end up nonsense. Q: Any plans for continuations? Coroutines? A: Maybe, and yes. (continuations are contingent on Dan understanding them, and he doesn't. Dunno why, might be because he writes about himself in the third person, the arrogant bastard) Er... any details on what the plans for coroutines might be? How will stack frames be handled? Q: Why aren't you reusing big gobs of the perl5 code? A: Licensing. As soon as we sort that out, we will. Q: Fine. But surely some pieces could be reused? A: Not until the licensing's sorted out. Then it depends on whether we can. Q: Oh. Why are licenses a problem? Doesn't the AL allow this sort of thing? A: IANAL, and I don't play one on TV, but snagging code under a licensing scheme does sort of obligate you to follow that license. Since we don't have one for Parrot source quite yet, I'd rather not. Hm. I need to ask that first question a different way. Assuming the licensing problems disappear in a puff of foul-smelling smoke, what aspects of perl5 code make it a pain to reuse? Q: Why do people yell at me when I send patches using // for comments? They're ANSI C, you know. A: C99, IIRC. I don't think original ANSI C accepted them, and that's all we're requiring at the moment. and I would think that which exact version of ANSI C supports them is irrelevant, since the *real* target is whatever subset of C is widely enough supported in the myriad compilers currently in use. Which probably bears some resemblance to C89 or whatever it's properly called. Q: What API will extension writers write to? A: Parrot's. More specifically, what can be relied upon for source compatibility and binary compatibility within a major version? (The currently defined PMC vtable entries for a given version?) Q: How will garbage collection interact with extensions? A: There'll be some caveats, but reasonably well. For the most part extension writers won't have to worry much about it, and we'll document the spots where they will. Parrot's potentially got a copying GC system, which means that tracked buffers may move, but you'll know which calls may allocate memory (and thus potentially cause movement). There'll be easy access to the GC controls so you can turn GC off if you need to. Q: How will finalization [or whatever the right word is] interact with extensions? A: You mean object destruction? Correctly. If you allocate a PMC within an extension subroutine, that PMC will be considered active at least until the end of the sub. Q: What's the difference between the previous two questions? A: The first deals with potentially reclaiming or moving allocated memory, the second with figuring out whether a variable is dead or not. How do DESTROY subs fit in? I think you've described this elsewhere, so this answer can just be a pointer. Q: In what format will Parrot files be stored? A: I presume you mean data files. They won't be anything special--plain text files, or DB/DBM/[SGN]DBM, or whatever. If you mean parrot bytecode files, they'll be in our native format. (I meant bytecode) Q: Why aren't you using something like ELF as the on-disk binary format? A: Portability. Another topic I know
Re: Parrot FAQ
On Wed, Dec 05, 2001 at 11:02:34AM -0500, Dan Sugalski wrote: Q: How do Dan and Simon have enough time to work on this? A: We don't--why do you think this is taking so long? A related FAQable question ... Q: Is it possible to buy Dan's and Simon's time to work on nothing but Parrot? If so, how? And for my own personal edification, has anyone tried to work a deal (through YAS perhaps) for Parrot like Damian Conway has for Perl? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
re: Various pre-0.0.3 updates.
Since 0.0.3 is exceptionally imminent, can I have a roll-call of systems which are working and not working? OS/2 + EMX Working Tinderbox + internal lan with private dns + os/2 sendmail broke, hence its not in the tinderbox... Nick
re: Various pre-0.0.3 updates.
At 07:46 PM 12/5/2001 +, Nick Burch wrote: Since 0.0.3 is exceptionally imminent, can I have a roll-call of systems which are working and not working? OS/2 + EMX Working Tinderbox + internal lan with private dns + os/2 sendmail broke, hence its not in the tinderbox... FWIW, I was mailed a config file to use Net::SMTP instead of sendmail, if that'd help. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot FAQ
On Tue, 04 Dec 2001 15:57:56 -0500, Dan Sugalski wrote: Q: Don't you know that stack machines are the way to go in software? A: No, in fact, I don't. Q: But look at all the successful stack-based VMs! A: Like what? There's just the JVM. Q: What about all the others? A: *What* others? That's it, unless you count perl, python, or ruby. I thought Pascal's (ancient) p-code was a stack VM... Yup, some web pages that I can find in a hurry, confirm that. http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?P-code -- Bart.
Fixed Tindermail.pm
Here is a fixed tindermail that uses SMTP for those that are having problems with sendmail. Modify the ### Configuration ### section before using. Please tell me if you find any bugs :) (file attached, CRLF newlines probably) -Jaen Saul Tindermail.pm Description: Binary data
Oops. :) I missed a point.
make distclean should clean everything so ignore my point about leaving the CVS directories :) And please leave me a message when the makefiles are fixed so I can delete my custom version of makefile.in. -Jaen Saul
patch for eq and ne (lt and gt maybe coming later)
This is a patch for eq and ne that supports more combinations of
I, N and S, including ones that may be considered redundant.
There is also default popping of the call stack if there is no
branch address specified. I understand that I can branch to an
intermediate label and call ret myself, but I'd like a more
concise way.
If this one is ok with you guys, I will patch lt and gt similarly.
An example will be posted in a separate email shortly.
-Hao
--- core.opsWed Dec 5 11:54:44 2001
+++ core.ops.oldWed Dec 5 10:41:31 2001
@@ -447,245 +447,73 @@
-=item Beq(i|ic, i|ic)
+=item Beq(i, i, ic)
-=item Beq(n|nc, n|nc)
+=item Beq(i, ic, ic)
-=item Beq(s|sc, s|sc)
+=item Beq(n, n, ic)
-=item Beq(i|ic, i|ic, ic)
+=item Beq(n, nc, ic)
-=item Beq(n|nc, n|nc, ic)
+=item Beq(s, s, ic)
-=item Beq(s|sc, s|sc, ic)
+=item Beq(s, sc, ic)
Branch if $1 is equal to $2.
-Return address is popped off the call stack if no address is supplied.
-
=cut
-AUTO_OP eq (i, i|ic) {
- opcode_t *dest;
- if ($1 == $2) {
-pop_generic_entry (
- interpreter, interpreter-control_stack_top,
- dest, STACK_ENTRY_DESTINATION
-);
-RETABS(dest);
- }
-}
-
-AUTO_OP eq (ic, i|ic) {
- opcode_t *dest;
- if ($1 == $2) {
-pop_generic_entry (
- interpreter, interpreter-control_stack_top,
- dest, STACK_ENTRY_DESTINATION
-);
-RETABS(dest);
- }
-}
-
-AUTO_OP eq (n, n|nc) {
- opcode_t *dest;
- if ($1 == $2) {
-pop_generic_entry (
- interpreter, interpreter-control_stack_top,
- dest, STACK_ENTRY_DESTINATION
-);
-RETABS(dest);
- }
-}
-
-AUTO_OP eq (nc, n|nc) {
- opcode_t *dest;
- if ($1 == $2) {
-pop_generic_entry (
- interpreter, interpreter-control_stack_top,
- dest, STACK_ENTRY_DESTINATION
-);
-RETABS(dest);
- }
-}
-
-AUTO_OP eq (s, s|sc) {
- opcode_t *dest;
- if (string_compare (interpreter, $1, $2) == 0) {
-pop_generic_entry (
- interpreter, interpreter-control_stack_top,
- dest, STACK_ENTRY_DESTINATION
-);
-RETABS(dest);
- }
-}
-
-AUTO_OP eq (sc, s|sc) {
- opcode_t *dest;
- if (string_compare (interpreter, $1, $2) == 0) {
-pop_generic_entry (
- interpreter, interpreter-control_stack_top,
- dest, STACK_ENTRY_DESTINATION
-);
-RETABS(dest);
- }
-}
-
AUTO_OP eq(i, i|ic, ic) {
if ($1 == $2) {
RETREL($3);
}
}
-AUTO_OP eq (ic, i|ic, ic) {
- if ($1 == $2) {
-RETREL($3);
- }
-}
-
AUTO_OP eq(n, n|nc, ic) {
if ($1 == $2) {
RETREL($3);
}
}
-AUTO_OP eq (nc, n|nc, ic) {
- if ($1 == $2) {
-RETREL($3);
- }
-}
-
AUTO_OP eq(s, s|sc, ic) {
if (string_compare(interpreter, $1, $2) == 0) {
RETREL($3);
}
}
-AUTO_OP eq (sc, s|sc, ic) {
- if (string_compare (interpreter, $1, $2) == 0) {
-RETREL($3);
- }
-}
-
-=item Bne(i|ic, i|ic)
+=item Bne(i, i, ic)
-=item Bne(n|nc, n|nc)
+=item Bne(i, ic, ic)
-=item Bne(s|sc, s|sc)
+=item Bne(n, n, ic)
-=item Bne(i|ic, i|ic, ic)
+=item Bne(n, nc, ic)
-=item Bne(n|nc, n|nc, ic)
+=item Bne(s, s, ic)
-=item Bne(s|sc, s|sc, ic)
+=item Bne(s, sc, ic)
Branch if $1 is not equal to $2.
-Return address is popped off the call stack if no address is supplied.
-
=cut
-AUTO_OP ne (i, i|ic) {
- opcode_t *dest;
- if ($1 != $2) {
-pop_generic_entry (
- interpreter, interpreter-control_stack_top,
- dest, STACK_ENTRY_DESTINATION
-);
-RETABS(dest);
- }
-}
-
-AUTO_OP ne (ic, i|ic) {
- opcode_t *dest;
- if ($1 != $2) {
-pop_generic_entry (
- interpreter, interpreter-control_stack_top,
- dest, STACK_ENTRY_DESTINATION
-);
-RETABS(dest);
- }
-}
-
-AUTO_OP ne (n, n|nc) {
- opcode_t *dest;
- if ($1 != $2) {
-pop_generic_entry (
- interpreter, interpreter-control_stack_top,
- dest, STACK_ENTRY_DESTINATION
-);
-RETABS(dest);
- }
-}
-
-AUTO_OP ne (nc, n|nc) {
- opcode_t *dest;
- if ($1 != $2) {
-pop_generic_entry (
- interpreter, interpreter-control_stack_top,
- dest, STACK_ENTRY_DESTINATION
-);
-RETABS(dest);
- }
-}
-
-AUTO_OP ne (s, s|sc) {
- opcode_t *dest;
- if (string_compare (interpreter, $1, $2) != 0) {
-pop_generic_entry (
- interpreter, interpreter-control_stack_top,
- dest, STACK_ENTRY_DESTINATION
-);
-RETABS(dest);
- }
-}
-
-AUTO_OP ne (sc, s|sc) {
- opcode_t *dest;
- if (string_compare (interpreter, $1, $2) != 0) {
-pop_generic_entry (
- interpreter, interpreter-control_stack_top,
- dest, STACK_ENTRY_DESTINATION
-);
-RETABS(dest);
- }
-}
-
AUTO_OP ne(i, i|ic, ic) {
if ($1 != $2) {
RETREL($3);
}
}
-AUTO_OP ne (ic, i|ic, ic) {
- if ($1 != $2) {
-RETREL($3);
- }
-}
-
AUTO_OP ne(n, n|nc, ic) {
if ($1 != $2) {
RETREL($3);
}
}
-AUTO_OP ne (nc, n|nc, ic) {
- if ($1 != $2) {
-RETREL($3);
- }
-}
-
AUTO_OP ne(s, s|sc, ic) {
if
eq.pasm, tests and demonstrates eq
# # eq.pasm # # A program to test and demonstrate eq # # Copyright (C) 2001 Yet Another Society. All rights reserved. # This program is free software. It is subject to the same # license as The Parrot Interpreter. # bsrwaLA print ok\n bsriSA print ok\n bsrdalaWA print ok\n bsrtatLO print ok\n bsrApat print ok\n bsrliMA print ok\n bsrAnim print ok\n bsrPIto print ok\n bsrwaLO print ok\n bsrsiYAM print ok\n bsrsamPU print ok\n bsrlaBING print ok\n end waLA: setI0, 0 print I0 eq I0, I0 print not ret iSA: setI1, 1 print I1 eq I1, 1 print not ret dalaWA: setI2, 2 print I2 eq 2, I2 print not ret tatLO: print 3 eq 3, 3 print not ret Apat: setN4, 4.0 print 4 eq N4, N4 print not ret liMA: setN5, 5.0 print 5 eq N5, N5 print not ret Anim: setN6, 6.0 print 6 eq 6.0, N6 print not ret PIto: print 7 eq 7.0, 7.0 print not ret waLO: setS8, 8 print S8 eq S8, S8 print not ret siYAM: setS9, 9 print S9 eq S9, 9 print not ret samPU: setS10, 10 print S10 eq10, S10 print not ret laBING: print 11 eq11, 11 print not ret
Re: Parrot FAQ
And for my own personal edification, has anyone tried to work a deal (through YAS perhaps) for Parrot like Damian Conway has for Perl? That's a good question. I'll punt it off to someone else. Nat? Damian? YAS is on the very brink of announcing its 2002 funding drive. See: http://www.perl-foundation.org/ I believe it would not be inappropriate to reveal that, in addition to trying to fund me again for next year, YAS is hoping to raise enough donations to also purchase Dan's soul for 2002. I would expect that we would see formal announcements on yetanother.org, PerlMonks, use.perl, perl.com, c.l.p.m., Slashdot, and Good Morning America in the next day or so. Damian
Re: Parrot FAQ
Q: What about all the others? A: *What* others? That's it, unless you count perl, python, or ruby. I thought Pascal's (ancient) p-code was a stack VM... Yup, some web pages that I can find in a hurry, confirm that. Right, but back then they called 'em p-code interpreter which was far less pretentious. :) VB Benoit
Re: Moving string - number conversions to string libs
In message [EMAIL PROTECTED] James Mastros [EMAIL PROTECTED] wrote: On Mon, 3 Dec 2001, Tom Hughes wrote: It's completely wrong I would have thought - the encoding layer cannot know that a given code point is a digit so it can't possibly do string to number conversion. You need to use the encoding layer to fetch each character and then the character set layer to determine what digit it represents. Right. And then you need to apply some unified logic to get from this vector of digits (and other such symbols) to a value. Indeed, and that logic needs to be in the string layer where it can use both the encoding routines and the character type routines. I have just rearranged things to reflect that. I'm just having nightmares of subtily different definitions of what a numeric constant looks like depending on the string encoding, because of different bits o' code not being quite in sync. Code duplication bad, code sharing good. Absolutely. That code is now in one place. (The charset layer should still be involved somewhere, because Unicode (for ex) has a digit value property. This makes, say, aribic numerials (which don't look at all what what a normal person calls aribic numerals, BTW) work properly. (OTOH, it might also do strange things with ex Hebrew, where the letters are also numbers (Aleph is also 1, Bet is also 2, etc.)) So far I have added as is_digit() call to the character type layer to replace the existing isdigit() calls. To do things completely right we need to extend that with calls to get the digit value, check for sign characters etc, rather than assuming ASCIIish like it does now. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/
PATCH: test_prog -d flag
Here we go... Just adds the debug flag for test_prog.
-Melvin
--- orig/parrot/test_main.c Mon Oct 22 21:00:01 2001
+++ parrot/test_main.c Wed Dec 5 18:13:03 2001
@@ -20,6 +20,7 @@
int bounds_checking;
int profiling;
int tracing;
+int debugging;
struct Parrot_Interp *interpreter;
init_world();
@@ -36,6 +37,7 @@
bounds_checking = 0;
profiling = 0;
tracing = 0;
+debugging = 0;
while (argc 1 argv[1][0] == '-') {
if (argv[1][1] == 'b' argv[1][2] == '\0') {
@@ -59,6 +61,13 @@
}
argc--;
}
+else if (argv[1][1] == 'd' argv[1][2] == '\0') {
+debugging = 1;
+for(i = 2; i argc; i++) {
+argv[i-1] = argv[i];
+}
+argc--;
+}
}
/* If we got only the program name, complain */
@@ -105,6 +114,10 @@
return 1;
}
+if (debugging) {
+interpreter-flags |= PARROT_DEBUG_FLAG;
+}
+
if (bounds_checking) {
interpreter-flags |= PARROT_BOUNDS_FLAG;
}
Re: Parrot FAQ
On Wed, Dec 05, 2001 at 02:57:04PM -0500, Dan Sugalski wrote: Seriously, I can't speak for Simon, but I expect Things Can Be Worked Out given sufficient stuff. (I am, while easy, not cheap, alas. That whole spouse/kids/rent/insurance/unpaid time off day job thing) I am not sufficiently arrogant to believe that YAS should sponsor me, nor am I sufficiently humble to wonder why they haven't done so already. :) Seriously - I have a day job, which I enjoy very much. I don't really want to relinquish that at the moment. Maybe soon. In the interests of full disclosure, I also have a job with O'Reilly as perl.com editor, but I don't believe that it takes up sufficient time that it interferes with Parrot stuff. Doubly seriously - there are far more worthy people than I who YAS ought to sponsor before me. Consider Damian, Jarkko, Larry, Nick Clark, Nick I-S, ... -- If God had a beard, he'd be a UNIX programmer.
Re: Oops. :) I missed a point.
On Wed, Dec 05, 2001 at 10:44:09PM +0200, Jaen Saul wrote: make distclean should clean everything so ignore my point about leaving the CVS directories :) Uhm, it does clean everything. If I've coded it right, (cough cough) it deletes everything that's not in MANIFEST. -- ``Perl is the successfull attempt to make a braindump directly executable.'' - Lutz Donnerhacke in de.org.ccc
Resend - PATCH: test_prog -d flag
Yipes lemme resend that, I was dinking around with a new mailer and it blew the tab formatting. -Melvin add_debug1.patch Description: unknown/unknown
Re: PATCH: test_prog -d flag
On Wed, Dec 05, 2001 at 07:28:01PM -0500, [EMAIL PROTECTED] wrote: Here we go... Just adds the debug flag for test_prog. Thank you. I've applied that; I like it particularly because it doesn't actually add any more functionality. :) -- Simon: `hello kitty' douche. If you are getting some and you know what hello kitty is... Well, you're an exceptionally lucky man. -- Megahal, trained on IRC.
Re: Parrot FAQ
G'day all. On Wed, Dec 05, 2001 at 01:23:34PM -0500, Dan Sugalski wrote: Besides, the only p-code machine I could think of was UCSD Pascal running on the Apple IIs, and that seemed a bit old to reference. FWIW, in the last days of Microsoft's 16-bit C compiler (at least V7 and V8), it used to target something that they called p-code. Visual Basic still uses the interpreter (vbrun*.dll), I believe. Cheers, Andrew Bromage
interpreter-flags
Guys/Dan/Simon, While messing around tonight I noticed that interpreter flags aren't visible to any subsystem initialization code because the flags are passed to runops() instead of make_interpreter(). (I'm playing with some IO stuff and I'd like access to the flags at the time of the init code such as Init_IO() ) I'd suggest we initialize flags at the interpreter creation time, we could still clobber them with the runops() call but that is a little redundant unless there a reason to have both? -Melvin
Re: interpreter-flags
Correction, they aren't physically passed to runops() but you get the idea.. -Melvin ---Original Message--- From: Melvin Smith Date: Wednesday, December 05, 2001 08:49:30 PM To: [EMAIL PROTECTED] Subject: interpreter-flags Guys/Dan/Simon, While messing around tonight I noticed that interpreter flags aren't visible to any subsystem initialization code because the flags are passed to runops() instead of make_interpreter(). (I'm playing with some IO stuff and I'd like access to the flags at the time of the init code such as Init_IO() ) I'd suggest we initialize flags at the interpreter creation time, we could still clobber them with the runops() call but that is a little redundant unless there a reason to have both? -Melvin
Re: Moving string - number conversions to string libs
On Thu, 6 Dec 2001, Tom Hughes wrote: In message [EMAIL PROTECTED] James Mastros [EMAIL PROTECTED] wrote: On Mon, 3 Dec 2001, Tom Hughes wrote: It's completely wrong I would have thought - the encoding layer cannot know that a given code point is a digit so it can't possibly do string to number conversion. You need to use the encoding layer to fetch each character and then the character set layer to determine what digit it represents. Right. And then you need to apply some unified logic to get from this vector of digits (and other such symbols) to a value. Indeed, and that logic needs to be in the string layer where it can use both the encoding routines and the character type routines. I have just rearranged things to reflect that. Yes, that does make more sense. I think we need some string docs. Also, for string - integer conversion I think we ought to be scanning for a float then turning the result into an integer (as 1234.56e2 is one). We'll also eventually need a string-BigNum and string-BigInt conversion, and if things are to upgrade gracefully and silently this might need to happen as the string is scanned. Alex Gough
PATCH
This patch fixes a infinite loop ('./test_prog --' for example) in the
switch
handling in test_prog and also modifies make_interpreter() to pass
interpreter
flags as constructor argument.
-Melvin
pass_flags.patch
Description: unknown/unknown
Re: Key stuff for aggregates
--- Dan Sugalski [EMAIL PROTECTED] wrote:
At 10:28 AM 12/5/2001 -0500, Jason Gloudon wrote:
Using the aggregate's vtable is another way of getting
the job done that
avoids all the extra reference PMCs. However, references
will have to be
supported.
References are interesting. I'm currently thinking that:
*) PMCs should have a get_reference vtable entry
*) Accessing a reference should be just like accessing
the referent. (i.e.
you pass in the same key stuff and the reference vtable
does the indirect
lookup for you)
*) Some references will need to be 'smart', so if you do:
$foo = \@bar[4];
and @bar's a packed array, $foo's actually a fancy ref
that knows it points
to @bar[4] and calls @bar's vtables when you access it.
Or something like that.
This looks interesting, as far as it goes, but how will
parrot support the perl5ish
use overload
'@{}' = \deref_as_array,
'%{}' = \deref_as_hash;
? Do we pass in the PMC type that we want it to come back
as? But then how do we tell between the various types of
e.g. arrays. (To put it simply, how do you say I want an
arry. No, I don't _care_ if it's a PerlPMCArray or a
PerlIntArray or a PerlWhatHaveYouArray! ?)
-- BKS
__
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
