Re: PDD 6: Parrot Assembly Language
On Fri, Sep 07, 2001 at 04:30:56PM -0400, Dan Sugalski wrote: =item find_method Px, Py, tz Using what kind of dispatch mechanism? Or is that what the t is for? Simon
Re: String API
On Mon, Sep 10, 2001 at 04:48:35AM -0700, Benjamin Stuhl wrote: *cough* Namespace pollution *cough* These should proably all be prefixed... You're going to have a canary when you see the rest of the code... :) Seriously, I see the string subsystem as being self-sufficient; it can be detached from Parrot as a stand-alone string library, and hence shouldn't have Parrot_... prefices. Simon
Re: An overview of the Parrot interpreter
On 09/07/01 Dan Sugalski wrote: The only optimizations that interpreter had, were computed goto and allocating the eval stack with alloca() instead of malloc(). Doesn't this really get in the way of threading? You'll chew up great gobs of system stack, and that's a scarce resource when running with threads. The number of entries in the eval stack is bounded, I've never seen it grow past 13. I think they worked also on outputting IL bytecode... Yep, but that version was slower. Dick Hardt snagged me at TPC this year (I think I spent most of my non-speaking time being pinned to a table or bench by folks with Things To Say... :) and made a .NET pitch. They were going with the translation to .net but switched to embedding perl. It was a lot faster. (Brad Kuhn had a paper on translating perl to java bytecode and he had lots of trouble, but for different reasons) My point is that using their experience, a few changes should be designed to better support dynamic languages in the CLR in the same way that currently the research is focused on extending it for functional languages, generics etc. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better
Re: Math functions? (Particularly transcendental ones)
At 08:07 PM 9/9/2001 -0400, Uri Guttman wrote: DS == Dan Sugalski [EMAIL PROTECTED] writes: DS Yeah, I can't think of a good reason for a noop. We might have one DS anyway, though, just in case one comes along anyway. in a hardware cpu they were commonly used to fill an instruction slot to keep a pipeline filled, or to follow a branch decision, or to pad a long running op. Yup, I realize that. I wasn't sure that we might not have some sort of in-memory opcode whiteout thing we need to do, in which case it'd be useful and potentially faster than recalculating a bunch of jump addresses. Here's a dumb question: will parrot allow bytecode which is stored in a perl scalar to be executed? DS Yup, in a restricted sandbox too, if you want. That way we'll be DS able to serialize code to bytestreams, spit them across the 'net, DS and execute them on the other end. will the op code table need to be sent over if it is code from a module which defines new op codes? Basically we'll build a small freeze to disk section and send it over the wire instead of freezing to disk. It'll have all the standard stuff--fixup section, constants section, and code. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: String API
At 12:53 PM 9/10/2001 +0100, Nicholas Clark wrote:
On Sun, Sep 09, 2001 at 10:16:27PM +0100, Simon Cozens wrote:
=head1 Elements of the CSTRING structure
Those implementing the CSTRING API will obviously need to know about
how the CSTRING structure works. You can find the definition of this
structure in Fstring.h:
struct parrot_string {
void *bufstart;
IV buflen;
IV bufused;
IV flags;
IV strlen;
IV encoding;
IV type;
IV unused;
};
At some point on p5p Ilya Zakharevich expressed regret that perl5 doesn't
support split buffers. A split buffer would allow things like regular
expressions to run faster when repeatedly substituting in the middle of a
string, as it reduces the amount of data to copy. With a single contiguous
buffer
As Simon's said, the buffer can certainly be pointing to a fancier data
structure than heap 'o bytes. :) I hadn't considered that, though. I was
thinking that split strings would be dealt with at a higher-level of
abstraction--in the PMC (basically at the variable level) rather than in
the string itself.
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
RE: Math functions? (Particularly transcendental ones)
Uri Guttman wrote:
but having parrot op codes map to special instructions
makes sense only if we are doing some form of machine instruction
generation as with JIT or TIL.
Actually, I wasn't necessarily asking for any special ops (I'm not actually
asking for anything, it's just a suggestion), just that the boolean math
operations use a specific register or registers. I think this would make
implementing code generation on those platforms more straight-forward.
Things like:
if( $port_read 0xF7 ) {...
would tell perl to place the word into the bool-specific register, and the
implementation for the platform could then see that the operation on that
register would be a more likely candidate for optimizations such as:
LOW B0, AX ; get low-order byte of bool register (from DATA?)
BITT B0, 4 ; test bit4 of B0
or whatever the actual ASM ops are.
If the word were to be randomly assigned to any register, then all similar
operations would need to be tested for those potential optimizations. That's
not impossible, however in RT/embedded systems those ticks are at a premium.
Again, I'm not implying this is necessary, but only a suggestion. It may
however also offer gains in some internal (event?/flag?) operations.
Grant M.
P.S. Dan, looking forward to meeting you on Tuesday night.
[EMAIL PROTECTED]
Re: Math functions? (Particularly transcendental ones)
On Mon, 2001-09-10 at 08:47, Dan Sugalski wrote: At 08:07 PM 9/9/2001 -0400, Uri Guttman wrote: DS == Dan Sugalski [EMAIL PROTECTED] writes: DS Yeah, I can't think of a good reason for a noop. We might have one DS anyway, though, just in case one comes along anyway. in a hardware cpu they were commonly used to fill an instruction slot to keep a pipeline filled, or to follow a branch decision, or to pad a long running op. Yup, I realize that. I wasn't sure that we might not have some sort of in-memory opcode whiteout thing we need to do, in which case it'd be useful and potentially faster than recalculating a bunch of jump addresses. Here's a dumb question: will parrot allow bytecode which is stored in a perl scalar to be executed? DS Yup, in a restricted sandbox too, if you want. That way we'll be DS able to serialize code to bytestreams, spit them across the 'net, DS and execute them on the other end. will the op code table need to be sent over if it is code from a module which defines new op codes? Basically we'll build a small freeze to disk section and send it over the wire instead of freezing to disk. It'll have all the standard stuff--fixup section, constants section, and code. I was thinking about NOP this morning, and I realized that it might very well be necessary. If someone was writing a simple assembler for parrot, it might be useful for padding. Brian Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Math functions? (Particularly transcendental ones)
On Monday 10 September 2001 10:28 am, Brian Wheeler wrote: I was thinking about NOP this morning, and I realized that it might very well be necessary. If someone was writing a simple assembler for parrot, it might be useful for padding. Pad what? -- Bryan C. Warnock [EMAIL PROTECTED]
Muddled Boundaries - Perl 6 vs Parrot
Erk, we seem to be muddling around in that great grey area between what is Parrot and what is Perl. Parrot is striving to be a common backend for multiple scripting languages, of which one is Perl 6, no? And, of course, to adequately test Parrot, you need to concurrently develop Perl 6, yes? And that is what is currently happening, yes? No. (At least, it doesn't seem so.) Certainly, register creation, memory allocation, garbage collection, and opcode dispatch are definitely within the purview of Parrot. However, the opcodes' code themselves aren't - they're provided by the language. Of course, some concepts are global across multiple languages, so where *do* those commonalities lie? Are those things part of a Parrot sublanguage that all superlanguages are expected to build on top of? Parrot may provide facilities for vtable dispatch and string handling, but a language isn't roped into using them. Things to keep in mind. (And another reason why it's good to have Namespace Police :) -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Math functions? (Particularly transcendental ones)
On Mon, 2001-09-10 at 09:16, Bryan C. Warnock wrote: On Monday 10 September 2001 10:28 am, Brian Wheeler wrote: I was thinking about NOP this morning, and I realized that it might very well be necessary. If someone was writing a simple assembler for parrot, it might be useful for padding. Pad what? How about preserving offsets during an optimization phase: add i3,i1,1 add i3,i3,8 could become add i3,i1,9 nop without having to recompute offsets for later bytecode. In the same way, you could also use it for reserving space for things like debugging code, like adding 10 nops if debugging is turned off, and using those 10 instructions for debugging if it is turned onmaintaining the relative addresses of things. Of course, one could just recompile using the parrot assembler, so this would only be for those tinkering with their own assembler, I suppose. Honestly, I don't care either way, since add i0,i0,0 is the same (basically) as a nop, but takes a little more cpu. One could always #define nop add i0,i0,0 :) Brian
Re: Muddled Boundaries - Perl 6 vs Parrot
Bryan C. Warnock [EMAIL PROTECTED] wrote: Erk, we seem to be muddling around in that great grey area between what is Parrot and what is Perl. Yes, which leads me on to think... (With my maintainer of the Coding PDD hat on) Presumably we have to decide what bits of code have a Parrot_ prefix, and what bits are Perl_. And do we split off everything into two completely independent src trees, perhaps which compile to libparrot.a and libperl.a? Or this articifcal separation too hard to achieve in practice?
Re: Muddled Boundaries - Perl 6 vs Parrot
At 03:55 PM 9/10/2001 +0100, Dave Mitchell wrote: Bryan C. Warnock [EMAIL PROTECTED] wrote: Erk, we seem to be muddling around in that great grey area between what is Parrot and what is Perl. Yes, which leads me on to think... (With my maintainer of the Coding PDD hat on) Presumably we have to decide what bits of code have a Parrot_ prefix, and what bits are Perl_. And do we split off everything into two completely independent src trees, perhaps which compile to libparrot.a and libperl.a? Or this articifcal separation too hard to achieve in practice? We aren't going to split things out that hard. Generally speaking, the language-specific pieces will be: 1) Parser rules 2) Possibly compiler rules (maybe) 3) Variable vtable things So pretty much everything should have a Parrot_ prefix on it, with the (possible) exception of the perl variable vtable code. (Though I think those should probably be Parrot_ as well. We can change them to Perl_ at some point if it becomes appropriate) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Muddled Boundaries - Perl 6 vs Parrot
On Mon, Sep 10, 2001 at 10:29:13AM -0400, Bryan C. Warnock wrote: Parrot is striving to be a common backend for multiple scripting languages, of which one is Perl 6, no? And, of course, to adequately test Parrot, you need to concurrently develop Perl 6, yes? And that is what is currently happening, yes? No. (At least, it doesn't seem so.) We're developing a CPU. We're developing a compiler target. After all, how can you develop a compiler if you don't know what you're targeting it for? :) Certainly, register creation, memory allocation, garbage collection, and opcode dispatch are definitely within the purview of Parrot. However, the opcodes' code themselves aren't - they're provided by the language. Not really. Language-specific operations on Things are the purview of vtables. THEY're provided by the language. Simon
RE: Math functions? (Particularly transcendental ones)
Dan Sugalski: # At 10:08 AM 9/10/2001 -0700, Wizard wrote: # Uri Guttman wrote: ... # Okay, I see what you're aiming at. I don't think we will, # mainly because # it's not going to do us a whole lot of good. Parrot's got # more registers # than any system on the planet that I know of, so the bit that handles # converting to native machine code will need to do some analysis and # register renaming anyway. It can handle putting things in the # right places. I seem to remember reading in an article somewhere that Itanium has 128 registers. --Brent Dax [EMAIL PROTECTED] ...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet.
Re: Muddled Boundaries - Perl 6 vs Parrot
On Monday 10 September 2001 11:16 am, Dan Sugalski wrote: No. We don't need perl to test the interpreter. Parser and compiler, yes, interpreter no. The code that we are writing in assembler is Parrot opcode that we would expect a Perl parser and compiler to spit out. (That's all I'm saying) Certainly, register creation, memory allocation, garbage collection, and opcode dispatch are definitely within the purview of Parrot. However, the opcodes' code themselves aren't - they're provided by the language. Nope. The core opcodes are provided by the interpreter. A branch is a branch is a branch, no matter what language generated it. Yes, but what are you defining as core opcodes? Branches, okay. Basic math, okay. Basic string..., um, okay. Call and method dispatch, okay. Everything else in Perl that will eventually be an opcode? I hope not. Things to keep in mind. (And another reason why it's good to have Namespace Police :) For which reason we have brainwashed^Wrecruited Ben, it seems. Keen! (Smile and wave to the OMCL, Ben... :) Like I said, just things to keep in mind. There's a slight difference between designing and coding Parrot as an interpreter backend, and coding it as a backend to Perl that other languages can use. (I'm in favor of the latter, though public opinion seems to favor the former.) -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Muddled Boundaries - Perl 6 vs Parrot
Bryan C. Warnock writes: Like I said, just things to keep in mind. There's a slight difference between designing and coding Parrot as an interpreter backend, and coding it as a backend to Perl that other languages can use. (I'm in favor of the latter, though public opinion seems to favor the former.) Here's my Official Word. Right now it's too early to know whether building perl6's runtime to also support other languages will impact perl6's speed or size. We also have faced skepticism about the whole effort from other languages. So we're proceeding with designing perl6. We're leaving the door open for other languages, but we're not going to significantly delay or impede perl6 to support them. Dan and Simon have both been talking with Python folks about their language, and I'm sure there'll be demos to the Python crowd soon to show them that it's feasible and attempt to get their buy-in. If we get other languages interested to the point where we share our internals with them, then we'll go through the painful divorce process of dividing assets between Perl and Parrot. But until then, let's assume that Parrot will only officially be part of the Perl project, and focus on writing more Parrot code instead of arguing about namespaces. That may mean we may face a little pain down the road, but at the moment I'm much more interested in getting something to have pain about than I am about planning for a future that *might* come about. If we get the other languages interested, it'd be such a big win (in terms of development resources) that we'd be *happy* to do the work of separating parrot from perl. Make sense? Nat
Re: Muddled Boundaries - Perl 6 vs Parrot
On Monday 10 September 2001 12:58 pm, Nathan Torkington wrote: Here's my Official Word. Right now it's too early to know whether building perl6's runtime to also support other languages will impact perl6's speed or size. We also have faced skepticism about the whole effort from other languages. So we're proceeding with designing perl6. We're leaving the door open for other languages, but we're not going to significantly delay or impede perl6 to support them. Most excellent. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Math functions? (Particularly transcendental ones)
W == Wizard [EMAIL PROTECTED] writes:
W Uri Guttman wrote:
but having parrot op codes map to special instructions
makes sense only if we are doing some form of machine instruction
generation as with JIT or TIL.
W Actually, I wasn't necessarily asking for any special ops (I'm not
W actually asking for anything, it's just a suggestion), just that
W the boolean math operations use a specific register or registers. I
W think this would make implementing code generation on those
W platforms more straight-forward.
which level of code generation are you refering to? parrot op codes or
machine instructions?
W Things like:
Wif( $port_read 0xF7 ) {...
W would tell perl to place the word into the bool-specific register, and the
W implementation for the platform could then see that the operation on that
W register would be a more likely candidate for optimizations such as:
WLOW B0, AX ; get low-order byte of bool register (from DATA?)
WBITT B0, 4 ; test bit4 of B0
W or whatever the actual ASM ops are.
same question.
W If the word were to be randomly assigned to any register, then
W all similar operations would need to be tested for those potential
W optimizations. That's not impossible, however in RT/embedded
W systems those ticks are at a premium.
again, i think you are conflating parrot registers with machine
registers. they are not the same and there is no mapping from one to the
other on any particular platform. when we get to TIL or JIT which both
will generate real machine code, then architecture specific
optimizations will be addressed. right now the actual machine
architecture is (mostly) irrelevant in discussing parrot op
codes. parrot op codes will be implemented in portable c and not in
platform dependent assembler for the obvious portability reasons.
uri
PS. my cc's to you are bouncing with a delivery warning. this is replied
only to the list.
--
Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com
SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com
Search or Offer Perl Jobs -- http://jobs.perl.org
RE: Math functions? (Particularly transcendental ones)
Well, I used to do some embedded systems programming using C, and many of
the compilers would make attempts to optimize logical ops like
if( byte_variable 0xF7 ){...
into something using a processor op equivalent to the 8051C
testbit( byte_variable, bit_offset).
The 8051 processor has several direct, optimized, bit-test and manipulation
ops built-in, equivalent to the 8051C testbit, bitset, high, and low (and
probably more that I don't recall - it's been more than 10 years). These ops
were heavily used in embedded systems (they likely still are ;-).
The idea behind the separate boolean register(s) would be to make it
simpler for the implementer of perl on one of these targets to decide what
to test for optimization. It could also make it more better for
determining what ops require extended functionality (like carrys/overflows
for integers... or maybe not).
I have plans on being at your demo on Tuesday and, if you'd like, I think
I still have an old Intel 8051 code manual around somewhere that you can
have. Or if I'm not making myself clear enough (which happens fairly
regularly ;-), tell me... I promise not to be offended.
Let me know,
Grant M.
Re: String API
[EMAIL PROTECTED] (Simon Cozens) writes: =head2 Cunused This field is, as its name suggests, unused; however, it can be used to hold a pointer to the correct vtable for foreign strings. Wouldn't it be better to put a vtable * directly inside struct parrot_string instead of the 'encoding' enum? That would save the 'unused' slot for foreign encodings and you wouldn't need an additional layer of wrapper functions (or another way of indirection) for enc_foreign. The small integer ids you need for transcoding table lookups, etc. could be stored in a dedicated slot in the string vtables, or returned by a vtable function. -Edwin
Re: String API
Will the buffers associated with a string be managed by Parrot's memory management, and be visible to the garbage collector ? Or will these buffers be allocated from their own pool of memory not subject to garbage collection. -- Jason
FYI, that last email was sent last night...
I'm having trouble with my hosting company (wehost.net is poop!). That last email was a reply that I sent last night at 6pm. Please ignore it :-P Grant M.
Re: Muddled Boundaries - Perl 6 vs Parrot
At 01:20 PM 9/10/2001 -0400, Bryan C. Warnock wrote: On Monday 10 September 2001 01:08 pm, Simon Cozens wrote: And in addition - why are we worrying about namespace collision RIGHT NOW? Sure, when Parrot can be embedded, then we should ensure that our names aren't going to clash. But who in their right minds is going to embed Parrot in anything in its current state? (Leon, I said in their right minds) It's not a priority, compared to getting working code out there. We can sort it out later. Oh, how many times have I heard that before? Yeah, me too. :) Seriously, I think we should get it right from the start, if for no other reason than I can stop writing opcode and utility functions with the same name and coring the interpreter. (Which would be a nice change) It is my fault to begin with, since I started the show with no prefixes. It may also make things easier when we start dynaloading libraries, as we'll be doing pretty darned soon. (String and opcode function libraries, at least, and the rest will follow) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Math functions? (Particularly transcendental ones)
At 06:26 PM 9/9/2001 -0700, Wizard wrote: into something using a processor op equivalent to the 8051C testbit( byte_variable, bit_offset). This is pretty much testbit I0, 6 to test whether bit 6 is set i I0, right? Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Muddled Boundaries - Perl 6 vs Parrot
Bryan C. Warnock writes: It's not a prioirty, but it's so much easier to walk the correct path from the start. Since it's all Parrot, it's even easier. I agree. How about this: when the code is available (i.e., this afternoon), why don't you sit down with whoever else feels passionately about this, and add the namespace protection? There's no reason why it can't be added early, and I agree with Simon that he has higher priority things to worry about, but there's no reason why you or anyone else can't add it in. And it should be easy to add it in while the codebase is small. Namespace protection seems tricky. You need a list of symbols, categorized public or private. You need to automatically check the symbol list (e.g., output of nm) to see you're not exporting un-prefixed symbols. And so on. The more of this stuff that can be automated, the better. Go to it! Nat
RE: Math functions? (Particularly transcendental ones)
At 10:55 AM 9/10/2001 -0700, Hong Zhang wrote: At 06:26 PM 9/9/2001 -0700, Wizard wrote: into something using a processor op equivalent to the 8051C testbit( byte_variable, bit_offset). This is pretty much testbit I0, 6 to test whether bit 6 is set i I0, right? What is the difference from and I0, I0, (1 6) Well, I took a shortcut, it'd probably be: testbit I0, 6, SOME_LABEL_TO_JUMP_TO_IF_THE_BIT_IS_SET But I was posting mainly to get some clarification as to what Grant was talking about. Unless if we want Parrot to handle multi-media data, there is not reasons to introduce many bitops (such as rotate, leading zeros, trailing zeros). At the moment I tend to agree, but since perl has some bitwise operations we need to support at least those. I expect the bit ops will probably get consigned to a loadable library the same way that the transcendental ops will be, in which case it doesn't hurt to define a bunch for now since they won't get in the way. Besides, they are, if properly defined, useful. And they have the advantage that one or two people can split off to do them as they think necessary, so we can have another semi-independent development project. I don't want one or two people (Namely me... :) to be holding up development that other folks could be doing. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Muddled Boundaries - Perl 6 vs Parrot
--- Bryan C. Warnock [EMAIL PROTECTED] wisely wrote: On Monday 10 September 2001 01:08 pm, Simon Cozens wrote: And in addition - why are we worrying about namespace collision RIGHT NOW? Sure, when Parrot can be embedded, then we should ensure that our names aren't going to clash. But who in their right minds is going to embed Parrot in anything in its current state? (Leon, I said in their right minds) It's not a priority, compared to getting working code out there. We can sort it out later. Oh, how many times have I heard that before? It's not a prioirty, but it's so much easier to walk the correct path from the start. Since it's all Parrot, it's even easier. Hear, hear! I remember the pain in 5.005_5* of turning off PERL_POLLUTE. I expect that there may still be CPAN modules that won't build without manually defining it. It's much better if we get it right from the start so that there's less that we need to go back and fix. -- BKS __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/
Re: Math functions? (Particularly transcendental ones)
On Sat, Sep 08, 2001 at 12:00:24PM -0400, Dan Sugalski wrote: Okay, I'm whipping together the fancy math section of the interpreter assembly language. I've got: sin, cos, tan : Plain ones asin, acos, atan : arc-whatevers shinh, cosh, tanh : Hyperbolic whatevers log2, log10, log : Base 2, base 10, and explicit base logarithms pow : Raise x to the y power Can anyone think of things I've forgotten? It's been a while since I've done numeric work. FWIW, it's just dawned on me that if we want all of these things to be overloadable by PMCs, they need to have vtable entries. The PMC vtable is going to be considerably bigger than we anticipated. Simon
Re: Math functions? (Particularly transcendental ones)
At 09:15 PM 9/10/2001 +0100, Simon Cozens wrote: FWIW, it's just dawned on me that if we want all of these things to be overloadable by PMCs, they need to have vtable entries. The PMC vtable is going to be considerably bigger than we anticipated. Who the heck is going to override arctangent? (No, don't tell me, I don't want to know) For stuff like this I don't see a point in having a vtable entry for the transcendentals. atan is atan is atan. (Now, having said that, someone's going to define it for matrices or something wacky like that) At absolute worst I can see having a single vtable entry that gets passed in a transcendental function number or have the vtable be double-level for these, where there's just a pointer to transcendental functions table entry in the main vtable, so everyone shares the same table unless they want to get really extreme. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Math functions? (Particularly transcendental ones)
On Mon, 10 Sep 2001, Simon Cozens wrote: On Sat, Sep 08, 2001 at 12:00:24PM -0400, Dan Sugalski wrote: Okay, I'm whipping together the fancy math section of the interpreter assembly language. I've got: sin, cos, tan : Plain ones asin, acos, atan: arc-whatevers shinh, cosh, tanh : Hyperbolic whatevers log2, log10, log: Base 2, base 10, and explicit base logarithms pow : Raise x to the y power Can anyone think of things I've forgotten? It's been a while since I've done numeric work. FWIW, it's just dawned on me that if we want all of these things to be overloadable by PMCs, they need to have vtable entries. The PMC vtable is going to be considerably bigger than we anticipated. Does that mean that opcodes like these are just going to call functions pointed to by vtable entries (that is, not have a 'default implementation')? It makes more sense to me to just have these functions act on numbers (like float and bigfloat), and auto-numify like Perl 5 does. Forgive me if I am missing something (I usually am :). - D [EMAIL PROTECTED]
Re: Parrot 0.0.1 is released.
Patches should be sent to the perl6-internals mailing list, where I'll take a
look at them and apply them to the CVS tree.
Ooo, ooo - me first. Since you turned on -Wall in the Makefile I thought
it would be nice if it compiled without warnings. Below is a patch that
does that on my system.
This is the output from cvs -q diff -u. Is this is the best way to send
a multi-file patch from the CVS checkout?
-sam
Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.4
diff -u -r1.4 basic_opcodes.ops
--- basic_opcodes.ops 2001/09/10 15:48:36 1.4
+++ basic_opcodes.ops 2001/09/10 21:28:39
@@ -60,7 +60,7 @@
// PRINT Ix
AUTO_OP print_i {
- printf(I reg %i is %i\n, P1, INT_REG(P1));
+ printf(I reg %li is %li\n, P1, INT_REG(P1));
}
// BRANCH CONSTANT
@@ -152,7 +152,7 @@
// PRINT Nx
AUTO_OP print_n {
- printf(N reg %i is %Lf\n, P1, NUM_REG(P1));
+ printf(N reg %li is %Lf\n, P1, NUM_REG(P1));
}
// INC Nx
@@ -257,7 +257,7 @@
// PRINT Sx
AUTO_OP print_s {
STRING *s = STR_REG(P1);
- printf(S reg %i is %.*s\n, P1, string_length(s), s-bufstart);
+ printf(S reg %li is %.*s\n, P1, (int) string_length(s), (char *) s-bufstart);
}
// LEN Ix, Sx
@@ -272,4 +272,4 @@
// NOOP
AUTO_OP noop {
-}
\ No newline at end of file
+}
Index: bytecode.c
===
RCS file: /home/perlcvs/parrot/bytecode.c,v
retrieving revision 1.3
diff -u -r1.3 bytecode.c
--- bytecode.c 2001/09/10 09:50:39 1.3
+++ bytecode.c 2001/09/10 21:28:39
@@ -93,7 +93,7 @@
}
num--;
if (len 0 || (len 0 num == 0)) {
-printf(Bytecode error: string constant segment corrupted: %i, %i\n,
len, num);
+printf(Bytecode error: string constant segment corrupted: %i, %i\n,
+(int) len, (int) num);
exit(1);
}
}
Index: parrot.h
===
RCS file: /home/perlcvs/parrot/parrot.h,v
retrieving revision 1.2
diff -u -r1.2 parrot.h
--- parrot.h2001/09/07 15:23:40 1.2
+++ parrot.h2001/09/10 21:28:39
@@ -25,6 +25,7 @@
#include sys/stat.h
#include fcntl.h
#include errno.h
+#include string.h
#define NUM_REGISTERS 32
#define PARROT_MAGIC 0x13155a1
Index: register.c
===
RCS file: /home/perlcvs/parrot/register.c,v
retrieving revision 1.2
diff -u -r1.2 register.c
--- register.c 2001/09/10 15:49:27 1.2
+++ register.c 2001/09/10 21:28:39
@@ -10,10 +10,10 @@
struct IRegChunk *chunk_base;
chunk_base = CHUNK_BASE(interpreter-int_reg);
- printf(Chunk base is %x for %x\n, chunk_base, interpreter-int_reg);
+ printf(Chunk base is %x for %x\n, (unsigned int) chunk_base, (unsigned int)
+interpreter-int_reg);
/* Do we have any slots left in the current chunk? */
if (chunk_base-free) {
-printf(Free was %i\n, chunk_base-free);
+printf(Free was %i\n, (int) chunk_base-free);
interpreter-int_reg = chunk_base-IReg[chunk_base-used++];
chunk_base-free--;
}
Index: test_main.c
===
RCS file: /home/perlcvs/parrot/test_main.c,v
retrieving revision 1.2
diff -u -r1.2 test_main.c
--- test_main.c 2001/09/10 10:05:23 1.2
+++ test_main.c 2001/09/10 21:28:40
@@ -35,19 +35,19 @@
int i;
time_t foo;
- printf(String %p has length %i: %.*s\n, s, string_length(s),
string_length(s), s-bufstart);
+ printf(String %p has length %i: %.*s\n, s, (int) string_length(s), (int)
+string_length(s), (char *) s-bufstart);
string_concat(s, t, 0);
- printf(String %p has length %i: %.*s\n, s, string_length(s),
string_length(s), s-bufstart);
+ printf(String %p has length %i: %.*s\n, s, (int) string_length(s), (int)
+string_length(s), (char *) s-bufstart);
string_chopn(s, 4);
- printf(String %p has length %i: %.*s\n, s, string_length(s),
string_length(s), s-bufstart);
+ printf(String %p has length %i: %.*s\n, s, (int) string_length(s), (int)
+string_length(s), (char *) s-bufstart);
string_chopn(s, 4);
- printf(String %p has length %i: %.*s\n, s, string_length(s),
string_length(s), s-bufstart);
+ printf(String %p has length %i: %.*s\n, s, (int) string_length(s), (int)
+string_length(s), (char *) s-bufstart);
foo = time(0);
for (i = 0; i 1; i++) {
string_concat(s, t, 0);
string_chopn(s, 4);
}
- printf(1000 concats and chops took %i seconds.\n, time(0)-foo);
+ printf(1000 concats and chops took %li seconds.\n, time(0)-foo);
string_destroy(s);
}
/* Otherwise load in the program they gave and try that */
Re: PDD 6: Parrot Assembly Language
Dan Sugalski wrote: =item if tx, X, Y What's the purpose of providing Y? Does it make anything easier allowing Y != 0? =item jump tx I expected a call op too. Not a named sub call, but just call tx where tx has the same semantics as in jump. A return op is needed too. =item iton Nx, Iy =item ntoi Ix, Ny =item tostring Sx, ty, Iz Are these good names? They aren't very regular IMHO. Why is integer abbreviated i and string left spelled out? Why does tostring have three operands and the other two? =item inc tx, nn * =item dec tx, nn * Decrement register x by nn. nn is an integer constant. If nn is omitted, decrement by 1. Variable length ops don't sound so cool to me. Why not use add/sub to inc/dec by something other than 1? Also, it would be nice if inc/dec *always* kept Parrot semantics instead of automagically transmogrifying to Perl inc/dec. Is this the plan? =head2 Register and stack ops I'm a little confused why we can only push/pop entire register frames. Won't this make function value returns via registers impossible? IMHO, instead of push/pop a rotate command would be nice. That would allow SPARC-like register usage which has always seemed elegant to me. =item warp [string] Reset the current register stacks to the state they were in when the warp was set. Resets only the frame pointers, doesn't guarantee the contents of the registers. Be Ivery careful modifying the frame pointers by, for example, pushing register frames. I don't understand this explanation. It sounds like you are setting up co-routines or maybe resuming a continuation. Shouldn't the ops be a little safer? IMHO we don't want a co-routine construction set, we just want co-routines. =item find_lex Px, sy Find the lexical of name sy and store the PMC pointer in register Px. You're expecting the current lexical scope to be carried implicitly via the PC? Seems like find_lex should really be implemented as a vtable method on a compiler's scope object. =item find_method Px, Py, tz =item call_method Px, ty Multi-methods are notably absent. I'm assuming that Parrot does not understand multi-methods and requires the object (or the compiler generating the object) to register a multi-method dispatcher as the single-dispatch method known to Parrot. This only lets us use multi-methods where arg0 is an object. Is this sufficient for implementing Perl 6? - Ken
Re: Parrot 0.0.1 is released.
On Mon, Sep 10, 2001 at 09:42:38PM +0100, Simon Cozens wrote: From CPAN: http://www.cpan.org/authors/id/S/SI/SIMON/parrot-0.0.1.tar.gz http://www.cpan.org/src/parrot-0.0.1.tar.gz (once the mirrors have updated) From CVS: See the Parrot CVS home page at http://cvs.perl.org/ OK, I screwed that one up good and proper. :( Be nice, I'm new to this game. Please use the anon CVS where you can, because that'll always be up to date, and won't suffer from any packaging issues. Emergency fixed package available at http://www.netthink.co.uk/downloads/parrot-0.0.1.tar.gz I've even tested this one. Sorry, and this time, have more fun. Simon
Re: Parrot 0.0.1 is released.
On Mon, Sep 10, 2001 at 05:25:46PM -0400, Sam Tregar wrote: Ooo, ooo - me first. Since you turned on -Wall in the Makefile I thought it would be nice if it compiled without warnings. Below is a patch that does that on my system. Thanks, applied. (Although I consider it a temporary fix, because when we have a configure system and IV isn't necessarily a long, we'll need to do something more permanent.) This is the output from cvs -q diff -u. Is this is the best way to send a multi-file patch from the CVS checkout? Yes, thanks. Simon
Re: PDD 6: Parrot Assembly Language
At 05:41 PM 9/10/2001 -0400, Ken Fox wrote: Dan Sugalski wrote: =item if tx, X, Y What's the purpose of providing Y? Does it make anything easier allowing Y != 0? Hmmm. No, it doesn't, it just bloats out the opcode stream by an IV. I'll fix that. =item jump tx I expected a call op too. Not a named sub call, but just call tx where tx has the same semantics as in jump. A return op is needed too. In the next rev, I just haven't mailed it out yet. =item iton Nx, Iy =item ntoi Ix, Ny =item tostring Sx, ty, Iz Are these good names? They aren't very regular IMHO. Why is integer abbreviated i and string left spelled out? Why does tostring have three operands and the other two? No, because, and the third is a string type, on the off chance you wanted a non-native string. (Unicode, EBCDIC, whatever) Respectively. :) =item inc tx, nn * =item dec tx, nn * Decrement register x by nn. nn is an integer constant. If nn is omitted, decrement by 1. Variable length ops don't sound so cool to me. Why not use add/sub to inc/dec by something other than 1? They aren't variable length. They're actually inc_i inc_i_ic (and inc_n, inc_n_nc, and so on...) under the hood. The assembler is supposed to be smart enough to see you did: inc N2, 5 and know it's supposed to emit the inc_n_nc form. The assembler's not that smart yet. Also, it would be nice if inc/dec *always* kept Parrot semantics instead of automagically transmogrifying to Perl inc/dec. Is this the plan? Dunno what you mean. I N registers increment numerically, PMC registers get the variable's vtable inc function called, and I don't know what happens if we do it on a string register. We might not allow it. =head2 Register and stack ops I'm a little confused why we can only push/pop entire register frames. Won't this make function value returns via registers impossible? IMHO, instead of push/pop a rotate command would be nice. That would allow SPARC-like register usage which has always seemed elegant to me. There are things missing. There's a fetch from the past op, a push-with-clone op, and a push on the generic stack op. They're just not in the doc I mailed yet. =item warp [string] Reset the current register stacks to the state they were in when the warp was set. Resets only the frame pointers, doesn't guarantee the contents of the registers. Be Ivery careful modifying the frame pointers by, for example, pushing register frames. I don't understand this explanation. It sounds like you are setting up co-routines or maybe resuming a continuation. Shouldn't the ops be a little safer? IMHO we don't want a co-routine construction set, we just want co-routines. It's more for the case when we've pushed a few frames of registers and need to get back to the marker for a moment. Sort of like setjmp/longjmp/comefromjmp in C. (If it had a comefromjmp to undo the longjmp...) Might turn out to be a stupid thing. If so, it's out of there. =item find_lex Px, sy Find the lexical of name sy and store the PMC pointer in register Px. You're expecting the current lexical scope to be carried implicitly via the PC? No, it'll be in the interpreter struct. Seems like find_lex should really be implemented as a vtable method on a compiler's scope object. Well, if we had one we could, I suppose. =item find_method Px, Py, tz =item call_method Px, ty Multi-methods are notably absent. Haven't gotten there yet. I'm assuming that Parrot does not understand multi-methods and requires the object (or the compiler generating the object) to register a multi-method dispatcher as the single-dispatch method known to Parrot. Nope, multimethod dispatch will be built in, at least for some number of args. (At least 2, maybe more) It's a lot more efficient if parrot handles that. This only lets us use multi-methods where arg0 is an object. Is this sufficient for implementing Perl 6? Ummm... how on earth do you plan on calling a method of something that's not an object? Methods sorta require them... :) Anyway, I realized that bit of the PDD was unfinished after I sent it. I'd hoped to correct it before it got poked at, but didn't get a chance. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Patch to assembler/disassembler + parrot asm inconsistancies
First off, here's an inconsistancy I found: In test.pasm
REDO: eq_i_ic I2, I4, DONE, NEXT
appears. Shouldn't this be comparing to a constant, not a register? It
became a little obvious when I made a few changes to the
assembler/disassembler to give more details about the data (and to allow
shortcuts like add I1,I2,I3 to go to add_i I1,I2,I3, etc)
There's 3 pieces: opcode_table, disassemble.pl and assemble.pl
The opcode_table patch changes the argument encoding to use these terms:
# i Integer constant
# I Integer register
# n Numeric constant
# N Numeric register
# s String constant?
# S String register
# D Destination
The opcodes definitions were changed accordingly.
Disassemble.pl takes the new definitions and prints things out a little
prettier (test.pbc):
time_i I1
0008 set_i_ic I2 0
0014 set_i_ic I3 1
0020 set_i_ic I4 1000
002c eq_i_ic I2 4 0058 0040
0040 add_i I2 I2 I3
0050 branch_ic 002c
0058 time_i I5
0060 print_i I1
0068 print_i I5
0070 print_i I2
0078 sub_i I2 I5 I1
0088 print_i I2
0090 set_i_ic I1 3
009c mul_i I4 I4 I1
00ac iton_n_i N1 I4
00b8 iton_n_i N2 I2
00c4 print_i I4
00cc print_n N1
00d4 print_i I2
00dc print_n N2
00e4 div_n N1 N1 N2
00f4 print_n N1
It also skips the magic number, and skips (but doesn't handle) the
constant data. String registers aren't handled either...yet
assemble.pl: this just contains workarounds to the new opcode_table
format.
Brian
Lastly, here's the patch:
Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.5
diff -u -r1.5 assemble.pl
--- assemble.pl 2001/09/10 17:30:29 1.5
+++ assemble.pl 2001/09/10 22:04:29
@@ -10,6 +10,15 @@
%pack_type = (i = 'l',
n = 'd',
);
+my %real_type=('i'='i',
+ 'n'='n',
+ 'N'='i',
+ 'I'='i',
+ 'S'='i',
+ 's'='i',
+ 'D'='i');
+
+
my $sizeof_packi = length(pack($pack_type{i},1024));
@@ -20,6 +29,7 @@
s/^\s+//;
next unless $_;
my ($code, $name, $args, @types) = split /\s+/, $_;
+@types=map { $_ = $real_type{$_}} @types;
$opcodes{$name} = {CODE = $code,
ARGS = $args,
TYPES = [@types]
Index: disassemble.pl
===
RCS file: /home/perlcvs/parrot/disassemble.pl,v
retrieving revision 1.1
diff -u -r1.1 disassemble.pl
--- disassemble.pl 2001/08/29 12:07:02 1.1
+++ disassemble.pl 2001/09/10 22:04:29
@@ -7,10 +7,20 @@
my %unpack_type;
%unpack_type = (i = 'l',
+ I = 'l',
n = 'd',
+ N = 'l',
+ D = 'l',
+ S = 'l',
+ s = 'l',
);
my %unpack_size = (i = 4,
n = 8,
+ I = 4,
+ N = 4,
+ D = 4,
+ S = 4,
+ s = 4,
);
open OPCODES, opcode_table or die Can't get opcode table, $!/$^E;
@@ -28,16 +38,34 @@
}
}
+
$/ = \4;
+my $magic=;
+my $constants=;
+ $constants=;
+
+my $offset=0;
while () {
$code = unpack 'l', $_;
$args = $opcodes[$code]{ARGS};
-print $opcodes[$code]{NAME};
+my $op_offset=$offset;
+print sprintf(%08x,$offset), ,$opcodes[$code]{NAME};
+$offset+=4;
+
if ($args) {
foreach (1..$args) {
local $/ = \$unpack_size{$opcodes[$code]{TYPES}[$_-1]};
$data = ;
- print , unpack $unpack_type{$opcodes[$code]{TYPES}[$_-1]},
$data;+ $offset+=$ {$/ };
+ if($opcodes[$code]{TYPES}[$_-1] eq N ||
+ $opcodes[$code]{TYPES}[$_-1] eq I) {
+ print ,$opcodes[$code]{TYPES}[$_-1],unpack
$unpack_type{$opcodes[$code]{TYPES}[$_-1]}, $data;
+ } elsif($opcodes[$code]{TYPES}[$_-1] eq D) {
+ # handle destination
+ print
,sprintf(%08x,$op_offset+unpack($unpack_type{$opcodes[$code]{TYPES}[$_-1]},$data)*4);
+ } else {
+ print , unpack $unpack_type{$opcodes[$code]{TYPES}[$_-1]}, $data;
+ }
}
}
print \n;
Index: opcode_table
===
RCS file: /home/perlcvs/parrot/opcode_table,v
retrieving revision 1.5
diff -u -r1.5 opcode_table
--- opcode_table2001/09/10 15:48:36 1.5
+++ opcode_table2001/09/10 22:04:30
@@ -9,61 +9,70 @@
# not the type of the register or anything. So N3 is still an i, since
that
# 3 specifying the register should be packed as an integer.
+# Revised arg types:
+# i Integer constant
+# I Integer register
+# n Numeric constant
+#
Re: Patch to assembler/disassembler + parrot asm inconsistancies
At 05:23 PM 9/10/2001 -0500, Brian Wheeler wrote: First off, here's an inconsistancy I found: In test.pasm REDO: eq_i_ic I2, I4, DONE, NEXT appears. Shouldn't this be comparing to a constant, not a register? Nope, though if I let you in on the actual secret it's help. That should really be eq_i_ic_ic. (Well, actually there should be only one label, and we fall through otherwise. It's a bug in implementation and assembly, not opcode name... :) The intention is the last _x covers the last arg, the next to last covers the next to last arg, and so on. When we run out, we repeat the innermost type. The ultimate intention is that you'd write that as a plain: eq I2, I4, DONE, NEXT or probably eq I2, I4, DONE and either way the assembler would know DONE was a constant and we needed i registers since that was specified, and emit the eq_i_ic opcode. It became a little obvious when I made a few changes to the assembler/disassembler to give more details about the data (and to allow shortcuts like add I1,I2,I3 to go to add_i I1,I2,I3, etc) The opcode_table patch changes the argument encoding to use these terms: # i Integer constant # I Integer register # n Numeric constant # N Numeric register # s String constant? # S String register # D Destination I was using a trailing c to note a constant since we're using the opcode name as a C function name, and we're not counting on case-sensitivity in symbols. Other than that (well, and Simon has a patch in to the repository to yank out the opcode numbers entirely from opcode_table) it looks keen. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Patch to assembler/disassembler + parrot asm inconsistancies
On Mon, Sep 10, 2001 at 06:23:02PM -0400, Dan Sugalski wrote: That should really be eq_i_ic_ic. (Well, actually there should be only one label, and we fall through otherwise. It's a bug in implementation and assembly, not opcode name... :) Patches are... :) I was using a trailing c to note a constant since we're using the opcode name as a C function name, and we're not counting on case-sensitivity in symbols. *nodnod*. I knew there was a reason something smelt funny about that. Other than that (well, and Simon has a patch in to the repository to yank out the opcode numbers entirely from opcode_table) it looks keen. Brian, if you could cvs update (or grab the snapshot from http://www.netthink.co.uk/downloads/parrot-0.0.1.tar.gz) and rework your patch given Dan's comments, I'd appreciate it. Thanks, Simon
Re: Math functions? (Particularly transcendental ones)
On Mon, 10 Sep 2001 17:13:44 -0400, Dan Sugalski wrote: Who the heck is going to override arctangent? (No, don't tell me, I don't want to know) Perhaps you do. Think BigFloat. Or Complex. -- Bart.
Re: Speaking of namespaces...
On Mon, Sep 10, 2001 at 06:58:23PM -0400, Dan Sugalski wrote:
At 03:52 PM 9/10/2001 -0700, Damien Neil wrote:
Parrot fails to work in very obscure ways on FreeBSD. After some
poking around, I tracked the problem to the end op--this appears
to conflict with something inside libc. Renaming the op fixes the
problem.
Ah, that's what was killing the build on Nat's machine. Patch, by chance?
The following quick-and-dirty patch appears to work. This prefixes
all opcode functions with Parrot_op_. I'd have made the prefix
configurable, but the opcode generation is spread across three
different files.
(Aside: What's the best way to generate a useful patch with cvs?
The following comes from cvs -q diff -u.)
- Damien
Index: build_interp_starter.pl
===
RCS file: /home/perlcvs/parrot/build_interp_starter.pl,v
retrieving revision 1.2
diff -u -u -r1.2 build_interp_starter.pl
--- build_interp_starter.pl 2001/09/10 21:26:09 1.2
+++ build_interp_starter.pl 2001/09/10 23:07:08
@@ -27,7 +27,7 @@
my($name) = split /\s+/;
my $num = $count;
$num = 0 if $name eq 'end';
-print INTERP \tx[$num] = $name; \\\n;
+print INTERP \tx[$num] = Parrot_op_$name; \\\n;
$count++ unless $name eq 'end';
}
print INTERP } while (0);\n;
Index: make_op_header.pl
===
RCS file: /home/perlcvs/parrot/make_op_header.pl,v
retrieving revision 1.3
diff -u -u -r1.3 make_op_header.pl
--- make_op_header.pl 2001/09/10 21:26:09 1.3
+++ make_op_header.pl 2001/09/10 23:07:08
@@ -6,7 +6,7 @@
next if /^\s*#/ or /^\s*$/;
chomp;
($name, undef) = split /\t/, $_;
-print IV *$name(IV *, struct Perl_Interp *);\n;
+print IV *Parrot_op_$name(IV *, struct Perl_Interp *);\n;
}
BEGIN {
Index: process_opfunc.pl
===
RCS file: /home/perlcvs/parrot/process_opfunc.pl,v
retrieving revision 1.3
diff -u -u -r1.3 process_opfunc.pl
--- process_opfunc.pl 2001/09/10 21:26:09 1.3
+++ process_opfunc.pl 2001/09/10 23:07:08
@@ -105,7 +105,7 @@
my $line = shift;
my ($name) = $line =~ /AUTO_OP\s+(\w+)/;
-print OUTPUT IV *$name(IV cur_opcode[], struct Perl_Interp *interpreter) {\n;
+print OUTPUT IV *Parrot_op_$name(IV cur_opcode[], struct Perl_Interp
+*interpreter) {\n;
return($name, return cur_opcode +
. $opcode{$name}{RETURN_OFFSET}. ;\n}\n);
}
@@ -114,7 +114,7 @@
my $line = shift;
my ($name) = $line =~ /MANUAL_OP\s+(\w+)/;
-print OUTPUT IV *$name(IV cur_opcode[], struct Perl_Interp *interpreter) {\n;
+print OUTPUT IV *Parrot_op_$name(IV cur_opcode[], struct Perl_Interp
+*interpreter) {\n;
print OUTPUT IV return_offset = 1;\n;
return($name, return cur_opcode + return_offset;\n}\n);
}
Index: test.pbc
===
RCS file: /home/perlcvs/parrot/test.pbc,v
retrieving revision 1.2
diff -u -u -r1.2 test.pbc
Binary files /tmp/cvsqe7MSGr3cy and test.pbc differ
Re: Patch to assembler/disassembler + parrot asm inconsistancies
I think Dan mentioned this, but it looks like the suffixes can be derived from the args being passed in. That would greatly simply the assembler to just the function names: set, eq, add, branch. Were there problems with the scheme, is someone working on it, or did it fall through the cracks? (I'm very much in favor of such a change, and will pick it up if no one else is working on it.) -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Speaking of namespaces...
On Mon, Sep 10, 2001 at 04:04:20PM -0700, Damien Neil wrote:
The following quick-and-dirty patch appears to work. This prefixes
all opcode functions with Parrot_op_. I'd have made the prefix
configurable, but the opcode generation is spread across three
different files.
Oops--that breaks the assembler. This patch fixes the assembler to
work with the prior patch.
- Damien
Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.6
diff -u -u -r1.6 assemble.pl
--- assemble.pl 2001/09/10 21:26:08 1.6
+++ assemble.pl 2001/09/10 23:43:30
@@ -15,7 +15,7 @@
open GUTS, interp_guts.h;
my $opcode;
while (GUTS) {
-next unless /\tx\[(\d+)\] = ([a-z_]+);/;
+next unless /\tx\[(\d+)\] = Parrot_op_([a-z_]+);/;
$opcodes{$2}{CODE} = $1;
}
RE: Speaking of namespaces...
Damien Neil: # On Mon, Sep 10, 2001 at 06:58:23PM -0400, Dan Sugalski wrote: # At 03:52 PM 9/10/2001 -0700, Damien Neil wrote: # Parrot fails to work in very obscure ways on FreeBSD. After some # poking around, I tracked the problem to the end op--this appears # to conflict with something inside libc. Renaming the op fixes the # problem. # # Ah, that's what was killing the build on Nat's machine. # Patch, by chance? # # The following quick-and-dirty patch appears to work. This prefixes # all opcode functions with Parrot_op_. I'd have made the prefix # configurable, but the opcode generation is spread across three # different files. # # (Aside: What's the best way to generate a useful patch with cvs? # The following comes from cvs -q diff -u.) This patch seems to work on the FreeBSD box I have access to. Now to figure out what's causing all those 'use of uninitialized value at assembler.pl line 81' messages... --Brent Dax [EMAIL PROTECTED] ...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet.
RE: Speaking of namespaces...
Damien Neil: # On Mon, Sep 10, 2001 at 04:04:20PM -0700, Damien Neil wrote: # The following quick-and-dirty patch appears to work. This prefixes # all opcode functions with Parrot_op_. I'd have made the prefix # configurable, but the opcode generation is spread across three # different files. # # Oops--that breaks the assembler. This patch fixes the assembler to # work with the prior patch. That explains it! :^) --Brent Dax [EMAIL PROTECTED] ...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet.
RE: Parrot 0.0.1 is released.
Am I missing something (well, clearly I am), but are test.pasm and test2.pasm missing from the CVS repository? // Jeffrey Coleman Carlyle: Computer Science Graduate Student at the // University of Illinois at Urbana-Champaign; Creator of StratoSetup, // Windows Restart, comp.os.msdos.programmer FAQ; Kentucky roadgeek; // RULER OF EARTH! www.rulerofearth.org www.jeffc.org -Original Message- From: Simon Cozens [mailto:[EMAIL PROTECTED]] Sent: Monday, September 10, 2001 3:43 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Parrot 0.0.1 is released. Because the game of hide-and-seek was still going on, it took Edmund and Lucy some time to find the others. But when at last they were all together (which happened in the long room, where the suit of armour was) Lucy burst out: Peter! Susan! It's all true. Edmund has seen it too. There is a country you can get to through the wardrobe. Edmund and I both got in. We met one another in there, in the wood. Go on, Edmund; tell them all about it. - The Lion, The Witch and the Wardrobe, CS Lewis I suppose (unlike Edmund did) I should tell you all about it. What we're releasing today is a very, very early alpha of the Parrot interpreter. At the moment, we have support for some simple operations on integer, floating point and string registers, and the ability to read in and execute bytecode. We also have an assembler which can generate bytecode output from Parrot assembly. You can get the source tarball in (currently) two different ways: From CPAN: http://www.cpan.org/authors/id/S/SI/SIMON/parrot-0.0.1.tar.gz http://www.cpan.org/src/parrot-0.0.1.tar.gz (once the mirrors have updated) From CVS: See the Parrot CVS home page at http://cvs.perl.org/ Once you've unpacked parrot, you should be able to make test_prog, and use the Parrot assembler to turn assembly into bytecode: make test_prog perl assemble.pl test.pasm test.pbc ./test_prog test.pbc perl assemble.pl test2.pasm test2.pbc ./test_prog test2.pbc The first test program will add some numbers together, count to 10,000,000, and tell you how long it took; the second test program will print a familiar greeting. In the next email, coming in a couple of minutes, I'll outline two areas where I really, really need some patches before we go much further; you should also note that Parrot has a bug/request tracking system at http://parrotbugs.develooper.com/ which will be filled with some more things that I'd like people to take a look at. Patches should be sent to the perl6-internals mailing list, where I'll take a look at them and apply them to the CVS tree. As time goes by, people who regularly submit good patches will be given committer access to the tree, and can help me out applying other patches from the list. IMPORTANT! Please note that we haven't decided the final license for Parrot yet. You currently receive Parrot under the same terms as Perl 5: your choice of either the Artistic or General Public Licenses. Have fun, Simon -- set_s_sc S1, Just Another Parrot Hacker, print_s S1
Re: Patch to assembler/disassembler + parrot asm inconsistancies
On Monday 10 September 2001 06:23 pm, Dan Sugalski wrote: At 05:23 PM 9/10/2001 -0500, Brian Wheeler wrote: First off, here's an inconsistancy I found: In test.pasm REDO: eq_i_ic I2, I4, DONE, NEXT appears. Shouldn't this be comparing to a constant, not a register? Nope, though if I let you in on the actual secret it's help. That should really be eq_i_ic_ic. (Well, actually there should be only one label, and we fall through otherwise. It's a bug in implementation and assembly, not opcode name... :) The intention is the last _x covers the last arg, the next to last covers the next to last arg, and so on. When we run out, we repeat the innermost type. Why are you doing right-to-left instead of left-to-right? -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Patch to assembler/disassembler + parrot asm
At 05:23 PM 9/10/2001 -0500, Brian Wheeler wrote: First off, here's an inconsistancy I found: In test.pasm REDO: eq_i_ic I2, I4, DONE, NEXT appears. Shouldn't this be comparing to a constant, not a register? Nope, though if I let you in on the actual secret it's help. That should really be eq_i_ic_ic. (Well, actually there should be only one label, and we fall through otherwise. It's a bug in implementation and assembly, not opcode name... :) The intention is the last _x covers the last arg, the next to last covers the next to last arg, and so on. When we run out, we repeat the innermost type. The ultimate intention is that you'd write that as a plain: eq I2, I4, DONE, NEXT or probably eq I2, I4, DONE and either way the assembler would know DONE was a constant and we needed i registers since that was specified, and emit the eq_i_ic opcode. BUT, I'm more confused now :) If eq_i_ic is really treated as /eq(_i)+_ic/ then this code still doesn't work: eq_i_ic I1,I2,NEXT,DONE because that'd be like eq_i_i_ic_ic, right? I assume that opcodes aren't going to have variable arguments at this level, so there should be a one-to-one mapping between function and opcode, right? A thought (though gross): if we restrict mneumonics to not use the underscore, then anything after _ can be the op signature. The opcode_table could use these characters for different data types: integer i integer constantj numeric n numeric constanto address a string s string constant t The file could be reorganized as: set 2 i j set 2 i i set 2 n o set 2 s t The perl scripts which create the interfaces (process_opfunc.pl, etc) could use this information to create 4 opcodes: set_ij set_ii set_no set_st When the assembler comes across 'set I1,I2', It knows the set_ii form is the one to use. The disassembler can dump it as 'set_ii I1,I2' or (I suppose) as 'set I1,I2' Also, doing it this way takes out the special cases for the comparison and jump ops: the fixups are known to be done with things that have type 'a' It became a little obvious when I made a few changes to the assembler/disassembler to give more details about the data (and to allow shortcuts like add I1,I2,I3 to go to add_i I1,I2,I3, etc) The opcode_table patch changes the argument encoding to use these terms: # i Integer constant # I Integer register # n Numeric constant # N Numeric register # s String constant? # S String register # D Destination I was using a trailing c to note a constant since we're using the opcode name as a C function name, and we're not counting on case-sensitivity in symbols. fair enough... Other than that (well, and Simon has a patch in to the repository to yank out the opcode numbers entirely from opcode_table) it looks keen. I'll take a peek and see what all depends on the opcode_table file... Brian Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Patch to assembler/disassembler + parrot asm
another thought... A thought (though gross): if we restrict mneumonics to not use the underscore, then anything after _ can be the op signature. The opcode_table could use these characters for different data types: integer i integer constant j numeric n numeric constant o address a strings string constant t The file could be reorganized as: set 2 i j set 2 i i set 2 n o set 2 s t what if the table had another column (optional) at the end: set 2 i j set_i which gave the name of the C function which implemented it. that way the assembly ops are independant of the C function names and multiple ops could map to a single C routine (if needed) I've got to know...what's the significance of the magic number? :) Brian
Re: Patch to assembler/disassembler + parrot asm inconsistancies
Bryan C. Warnock wrote: On Monday 10 September 2001 06:23 pm, Dan Sugalski wrote: When we run out, we repeat the innermost type. Why are you doing right-to-left instead of left-to-right? Because it would be harder to repeat the innermost type then? ;) Most binary ops will take identical inner args. This is just a readability optimization to avoid things like _i_i. Avoiding type extensions completely seems best if the compiler and disassembler are smart enough. I'm not sure we'll be able to do that though -- more complex addressing modes may lose type info. (But that assumes someday we get more complex addressing modes... ;) - Ken
Re: Patch to assembler/disassembler + parrot asm inconsistancies
At 08:00 PM 9/10/2001 -0400, Bryan C. Warnock wrote: On Monday 10 September 2001 06:23 pm, Dan Sugalski wrote: At 05:23 PM 9/10/2001 -0500, Brian Wheeler wrote: First off, here's an inconsistancy I found: In test.pasm REDO: eq_i_ic I2, I4, DONE, NEXT appears. Shouldn't this be comparing to a constant, not a register? Nope, though if I let you in on the actual secret it's help. That should really be eq_i_ic_ic. (Well, actually there should be only one label, and we fall through otherwise. It's a bug in implementation and assembly, not opcode name... :) The intention is the last _x covers the last arg, the next to last covers the next to last arg, and so on. When we run out, we repeat the innermost type. Why are you doing right-to-left instead of left-to-right? Because I think backwards from most people, apparently. :) That and generally speaking if there are three args the second is the same type as the first, while the third is the variant. Generally. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Speaking of namespaces...
At 04:56 PM 9/10/2001 -0700, Brent Dax wrote: This patch seems to work on the FreeBSD box I have access to. Now to figure out what's causing all those 'use of uninitialized value at assembler.pl line 81' messages... It's the blank lines in opcode_table. The assembler (and disassembler) at some point didn't grok 'em. Patches have been applied, but you might've checked out before that happened. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Patch to assembler/disassembler + parrot asm inconsistancies
On Monday 10 September 2001 08:47 pm, Dan Sugalski wrote: Because I think backwards from most people, apparently. :) That and generally speaking if there are three args the second is the same type as the first, while the third is the variant. Generally. Tayyib. Handling constants now. Everything else seems to work on the assembler side. -- Bryan C. Warnock [EMAIL PROTECTED]
RE: Parrot 0.0.1 is released.
# -Original Message- # From: Jeffrey Coleman Carlyle [mailto:[EMAIL PROTECTED]] # Sent: Monday, September 10, 2001 5:04 PM # To: 'Simon Cozens' # Cc: [EMAIL PROTECTED] # Subject: RE: Parrot 0.0.1 is released. # # # Am I missing something (well, clearly I am), but are test.pasm and # test2.pasm missing from the CVS repository? Check the t/ directory. --Brent Dax [EMAIL PROTECTED] ...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet.
Re: Speaking of namespaces...
On Mon, Sep 10, 2001 at 08:48:48PM -0400, Dan Sugalski wrote: At 04:56 PM 9/10/2001 -0700, Brent Dax wrote: This patch seems to work on the FreeBSD box I have access to. Now to figure out what's causing all those 'use of uninitialized value at assembler.pl line 81' messages... It's the blank lines in opcode_table. The assembler (and disassembler) at some point didn't grok 'em. Patches have been applied, but you might've checked out before that happened. No, in this case, it's my fault. I didn't realize the assembler reads op name/number mappings out of interp_guts.h, so my patch broke the assembler. I'm thinking of writing something to generate a Parrot::Opcode.pm module, so code doesn't need to parse opcode_table and interp_guts.h. Sound reasonable? - Damien
Re: PDD 6: Parrot Assembly Language
Dan Sugalski wrote:
At 05:41 PM 9/10/2001 -0400, Ken Fox wrote:
You're expecting the current lexical scope to be carried implicitly
via the PC?
No, it'll be in the interpreter struct.
But how does the interpreter know where a lexical scope begins
and ends in the bytecode? For example, a jump FOO might change
scopes. How is the scope discovered?
This only lets us use multi-methods where arg0 is an object. Is
this sufficient for implementing Perl 6?
Ummm... how on earth do you plan on calling a method of something that's
not an object? Methods sorta require them... :)
sub add(int x, int y) : multi { ... }
sub add(int x, num y) : multi { ... }
sub add(num x, num y) : multi { ... }
That makes sense to me. My syntax is probably wrong, but the intention
is clear. I'd be surprised if Damian doesn't want this.
- Ken
Re: Parrot 0.0.1 is released.
Jeffrey Coleman Carlyle wrote: Am I missing something (well, clearly I am), but are test.pasm and test2.pasm missing from the CVS repository? Look in ./t - Ken
Re: Patch to assembler/disassembler + parrot asm inconsistancies
At 08:44 PM 9/10/2001 -0400, Bryan C. Warnock wrote: On Monday 10 September 2001 08:47 pm, Dan Sugalski wrote: Because I think backwards from most people, apparently. :) That and generally speaking if there are three args the second is the same type as the first, while the third is the variant. Generally. Tayyib. Is that a good thing or a bad thing? :) Handling constants now. Everything else seems to work on the assembler side. Keen. Constants are odd, since they can happen in a number of ways. Int and float constants get embedded in the opcode stream, the rest go into the constants section and fixup sections of the bytecode, and that's still in flux. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Speaking of namespaces...
At 05:49 PM 9/10/2001 -0700, Damien Neil wrote: On Mon, Sep 10, 2001 at 08:48:48PM -0400, Dan Sugalski wrote: At 04:56 PM 9/10/2001 -0700, Brent Dax wrote: This patch seems to work on the FreeBSD box I have access to. Now to figure out what's causing all those 'use of uninitialized value at assembler.pl line 81' messages... It's the blank lines in opcode_table. The assembler (and disassembler) at some point didn't grok 'em. Patches have been applied, but you might've checked out before that happened. No, in this case, it's my fault. I didn't realize the assembler reads op name/number mappings out of interp_guts.h, so my patch broke the assembler. Nothing should read out of interp_guts.h. That's autogenerated from opcode_table. Or it was yesterday, but things might've changed. :) I'm thinking of writing something to generate a Parrot::Opcode.pm module, so code doesn't need to parse opcode_table and interp_guts.h. Sound reasonable? Yes, please do. I knew we needed one the second time I needed to parse opcode_table, I just haven't stopped long enough to be lazy and still program. (In those cases I came to a full stop...) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: PDD 6: Parrot Assembly Language
At 09:05 PM 9/10/2001 -0400, Ken Fox wrote:
Dan Sugalski wrote:
At 05:41 PM 9/10/2001 -0400, Ken Fox wrote:
You're expecting the current lexical scope to be carried implicitly
via the PC?
No, it'll be in the interpreter struct.
But how does the interpreter know where a lexical scope begins
and ends in the bytecode? For example, a jump FOO might change
scopes. How is the scope discovered?
jump FOO
doesn't change scope.
newscope scope_template_in_fixup_section
does. And
exitscope
leaves one. :)
This only lets us use multi-methods where arg0 is an object. Is
this sufficient for implementing Perl 6?
Ummm... how on earth do you plan on calling a method of something that's
not an object? Methods sorta require them... :)
sub add(int x, int y) : multi { ... }
sub add(int x, num y) : multi { ... }
sub add(num x, num y) : multi { ... }
That makes sense to me. My syntax is probably wrong, but the intention
is clear. I'd be surprised if Damian doesn't want this.
Ah, multimethod subroutines. Those are a different beast entirely. For
those the destination sub code is responsible for dispatch, that way you
only pay the penalty to decode the arg types for those subs that actually
do multimethodish things.
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Parrot 0.0.1 is released.
At 09:06 PM 9/10/2001 -0400, Ken Fox wrote: Jeffrey Coleman Carlyle wrote: Am I missing something (well, clearly I am), but are test.pasm and test2.pasm missing from the CVS repository? Look in ./t Right. We moved them around a bit ago. Joys of a new project--everything's in flux, and the documentation doesn't quite keep pace. (Sometimes its ahead, sometimes its behind, but it beats having two source modules out of sync :) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Patch to assembler/disassembler + parrot asm inconsistancies
On Monday 10 September 2001 08:58 pm, Dan Sugalski wrote: Tayyib. Is that a good thing or a bad thing? :) It's an okay thing. Literally. Handling constants now. Everything else seems to work on the assembler side. Keen. Constants are odd, since they can happen in a number of ways. Int and float constants get embedded in the opcode stream, the rest go into the constants section and fixup sections of the bytecode, and that's still in flux. Yes, constants are the current problem child, because string and integer constants come down to the guts of the assembler the same way, and I can't base it off of the destination type. I think I'll need to do mangling beforehand, or come up with another mechanism. (One of which I already have in mind.) -- Bryan C. Warnock [EMAIL PROTECTED]
RE: Patch to assembler/disassembler + parrot asm
Dan Sugalski: ... # The jump ops will be easy to figure--either they'll take a # register, a # constant number, or a label. We don't allow labels that could # be confused # with registers. (No I0: anywhere...) Noo! How will I write really confusing JAPHs now? :^) --Brent Dax [EMAIL PROTECTED] ...and if the answers are inadequate, the pumpqueen will be overthrown in a bloody coup by programmers flinging dead Java programs over the walls with a trebuchet.
Re: PDD 6: Parrot Assembly Language
On Monday 10 September 2001 09:00 pm, Dan Sugalski wrote: But how does the interpreter know where a lexical scope begins and ends in the bytecode? For example, a jump FOO might change scopes. How is the scope discovered? jump FOO doesn't change scope. Is that a doesn't or won't? -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Speaking of namespaces...
On Mon, Sep 10, 2001 at 08:56:52PM -0400, Dan Sugalski wrote: I'm thinking of writing something to generate a Parrot::Opcode.pm module, so code doesn't need to parse opcode_table and interp_guts.h. Sound reasonable? Yes, please do. I knew we needed one the second time I needed to parse opcode_table, I just haven't stopped long enough to be lazy and still program. (In those cases I came to a full stop...) OK, I'll do that sometime tonight. Should it parse opcode_table, or should it be generated with the contents of opcode_table? - Damien
length_s_i patch
Okay, we'll start small. length_s_i is backwards - should be length_i_s.
Patch fixes code and test.
Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.6
diff -u -r1.6 basic_opcodes.ops
--- basic_opcodes.ops 2001/09/10 21:47:25 1.6
+++ basic_opcodes.ops 2001/09/11 01:13:43
@@ -311,7 +311,7 @@
}
// LEN Ix, Sx
-AUTO_OP length_s_i {
+AUTO_OP length_i_s {
INT_REG(P1) = string_length(STR_REG(P2));
}
Index: opcode_table
===
RCS file: /home/perlcvs/parrot/opcode_table,v
retrieving revision 1.6
diff -u -r1.6 opcode_table
--- opcode_table2001/09/10 21:26:09 1.6
+++ opcode_table2001/09/11 01:13:44
@@ -44,7 +44,7 @@
set_s_sc 2 i i
print_s1 i
-length_s_i 2 i i
+length_i_s 2 i i
chopn_s_ic 2 i i
# Comparators
Index: t/test2.pasm
===
RCS file: /home/perlcvs/parrot/t/test2.pasm,v
retrieving revision 1.1
diff -u -r1.1 test2.pasm
--- t/test2.pasm2001/09/10 22:18:43 1.1
+++ t/test2.pasm2001/09/11 01:13:44
@@ -2,7 +2,7 @@
set_i_ic I1, 0
set_s_sc S1, Hello World
REDO: eq_i_ic I1, I2, DONE, NEXT
-NEXT: length_s_i I1, S1
+NEXT: length_i_s I1, S1
print_s S1
chopn_s_ic S1, 1
branch_ic REDO
--
Bryan C. Warnock
[EMAIL PROTECTED]
RE: Patch to assembler/disassembler + parrot asm
At 06:16 PM 9/10/2001 -0700, Brent Dax wrote: Dan Sugalski: ... # The jump ops will be easy to figure--either they'll take a # register, a # constant number, or a label. We don't allow labels that could # be confused # with registers. (No I0: anywhere...) Noo! How will I write really confusing JAPHs now? :^) use APL; ? ;-P Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: PDD 6: Parrot Assembly Language
At 09:01 PM 9/10/2001 -0400, Bryan C. Warnock wrote: On Monday 10 September 2001 09:00 pm, Dan Sugalski wrote: But how does the interpreter know where a lexical scope begins and ends in the bytecode? For example, a jump FOO might change scopes. How is the scope discovered? jump FOO doesn't change scope. Is that a doesn't or won't? Won't. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Speaking of namespaces...
At 06:02 PM 9/10/2001 -0700, Damien Neil wrote: On Mon, Sep 10, 2001 at 08:56:52PM -0400, Dan Sugalski wrote: I'm thinking of writing something to generate a Parrot::Opcode.pm module, so code doesn't need to parse opcode_table and interp_guts.h. Sound reasonable? Yes, please do. I knew we needed one the second time I needed to parse opcode_table, I just haven't stopped long enough to be lazy and still program. (In those cases I came to a full stop...) OK, I'll do that sometime tonight. Should it parse opcode_table, or should it be generated with the contents of opcode_table? Parse opcode_table. Sync up your source first, there have been some changes to the format in the last few hours. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Patch: missing comparison _ics
This patch (temporarily) fixes the missing _ic on comparison opcodes.
Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.6
diff -u -r1.6 assemble.pl
--- assemble.pl 2001/09/10 21:26:08 1.6
+++ assemble.pl 2001/09/11 01:27:58
@@ -68,12 +68,12 @@
$args[0] = fixup($args[0])
if $opcode eq branch_ic and $args[0] =~ /[a-zA-Z]/;
-#if ($opcode eq eq_i_ic or $opcode eq lt_i_ic) {
-if ($opcode =~ /^(eq|ne|lt|le|gt|ge)_i_ic$/) {
+#if ($opcode eq eq_i_ic_ic or $opcode eq lt_i_ic_ic) {
+if ($opcode =~ /^(eq|ne|lt|le|gt|ge)_i_ic_ic$/) {
$args[2] = fixup($args[2]) if $args[2] =~ /[a-zA-Z]/;
$args[3] = fixup($args[3]) if $args[3] =~ /[a-zA-Z]/;
}
-if ($opcode eq if_i_ic) {
+if ($opcode eq if_i_ic_ic) {
$args[1] = fixup($args[1]) if $args[1] =~ /[a-zA-Z]/;
$args[2] = fixup($args[2]) if $args[2] =~ /[a-zA-Z]/;
}
Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.6
diff -u -r1.6 basic_opcodes.ops
--- basic_opcodes.ops 2001/09/10 21:47:25 1.6
+++ basic_opcodes.ops 2001/09/11 01:27:58
@@ -41,7 +41,7 @@
}
// EQ Ix, Iy, EQ_BRANCH, NE_BRANCH
-MANUAL_OP eq_i_ic {
+MANUAL_OP eq_i_ic_ic {
if (INT_REG(P1) == INT_REG(P2)) {
RETURN(P3);
} else {
@@ -50,7 +50,7 @@
}
// NE Ix, Iy, NE_BRANCH, EQ_BRANCH
-MANUAL_OP ne_i_ic {
+MANUAL_OP ne_i_ic_ic {
if (INT_REG(P1) != INT_REG(P2)) {
RETURN(P3);
} else {
@@ -59,7 +59,7 @@
}
// LT Ix, Iy, LT_BRANCH, GE_BRANCH
-MANUAL_OP lt_i_ic {
+MANUAL_OP lt_i_ic_ic {
if (INT_REG(P1) INT_REG(P2)) {
RETURN(P3);
} else {
@@ -68,7 +68,7 @@
}
// LE Ix, Iy, LE_BRANCH, GT_BRANCH
-MANUAL_OP le_i_ic {
+MANUAL_OP le_i_ic_ic {
if (INT_REG(P1) = INT_REG(P2)) {
RETURN(P3);
} else {
@@ -77,7 +77,7 @@
}
// GT Ix, Iy, GT_BRANCH, LE_BRANCH
-MANUAL_OP gt_i_ic {
+MANUAL_OP gt_i_ic_ic {
if (INT_REG(P1) INT_REG(P2)) {
RETURN(P3);
} else {
@@ -86,7 +86,7 @@
}
// GE Ix, Iy, GE_BRANCH, LT_BRANCH
-MANUAL_OP ge_i_ic {
+MANUAL_OP ge_i_ic_ic {
if (INT_REG(P1) = INT_REG(P2)) {
RETURN(P3);
} else {
@@ -95,7 +95,7 @@
}
// IF IXx, TRUE_BRANCH, FALSE_BRANCH
-MANUAL_OP if_i_ic {
+MANUAL_OP if_i_ic_ic {
if (INT_REG(P1)) {
RETURN(P2);
} else {
@@ -178,7 +178,7 @@
}
// EQ Nx, Ny, EQ_BRANCH, NE_BRANCH
-MANUAL_OP eq_n_ic {
+MANUAL_OP eq_n_ic_ic {
if (NUM_REG(P1) == NUM_REG(P2)) {
RETURN(P3);
} else {
@@ -187,7 +187,7 @@
}
// IF Nx, TRUE_BRANCH, FALSE_BRANCH
-MANUAL_OP if_n_ic {
+MANUAL_OP if_n_ic_ic {
if (NUM_REG(P1)) {
RETURN(P2);
} else {
@@ -311,7 +311,7 @@
}
// LEN Ix, Sx
-AUTO_OP length_s_i {
+AUTO_OP length_i_s {
INT_REG(P1) = string_length(STR_REG(P2));
}
Index: opcode_table
===
RCS file: /home/perlcvs/parrot/opcode_table,v
retrieving revision 1.6
diff -u -r1.6 opcode_table
--- opcode_table2001/09/10 21:26:09 1.6
+++ opcode_table2001/09/11 01:27:58
@@ -44,25 +44,25 @@
set_s_sc 2 i i
print_s1 i
-length_s_i 2 i i
+length_i_s 2 i i
chopn_s_ic 2 i i
# Comparators
-eq_i_ic4 i i i i
-eq_n_ic4 i i i i
-ne_i_ic4 i i i i
-lt_i_ic4 i i i i
-le_i_ic4 i i i i
-gt_i_ic4 i i i i
-ge_i_ic4 i i i i
+eq_i_ic_ic 4 i i i i
+eq_n_ic_ic 4 i i i i
+ne_i_ic_ic 4 i i i i
+lt_i_ic_ic 4 i i i i
+le_i_ic_ic 4 i i i i
+gt_i_ic_ic 4 i i i i
+ge_i_ic_ic 4 i i i i
# Flow control
jump_i 1 i
branch_ic 1 i
-if_i_ic3 i i i
-if_n_ic3 i i i
+if_i_ic_ic 3 i i i
+if_n_ic_ic 3 i i i
# Convertors
Index: t/test.pasm
===
RCS file: /home/perlcvs/parrot/t/test.pasm,v
retrieving revision 1.1
diff -u -r1.1 test.pasm
--- t/test.pasm 2001/09/10 22:18:43 1.1
+++ t/test.pasm 2001/09/11 01:27:58
@@ -2,7 +2,7 @@
set_i_ic I2, 0
set_i_ic I3, 1
set_i_ic I4, 1000
-REDO: eq_i_ic I2, I4, DONE, NEXT
+REDO: eq_i_ic_ic I2, I4, DONE, NEXT
NEXT: add_i I2, I2, I3
branch_ic REDO
DONE: time_i I5
Index: t/test2.pasm
===
RCS file: /home/perlcvs/parrot/t/test2.pasm,v
retrieving revision 1.1
diff -u -r1.1 test2.pasm
--- t/test2.pasm2001/09/10 22:18:43 1.1
+++ t/test2.pasm2001/09/11 01:27:58
@@ -1,8 +1,8 @@
set_i_ic I2, 1
set_i_ic I1, 0
set_s_sc S1, Hello World
-REDO: eq_i_ic I1, I2, DONE, NEXT
-NEXT: length_s_i I1, S1
+REDO:
Re: PDD 6: Parrot Assembly Language
At 09:26 PM 9/10/2001 -0400, Ken Fox wrote:
Dan Sugalski wrote:
jump FOO
doesn't change scope.
newscope scope_template_in_fixup_section
does. And
exitscope
leaves one. :)
Ok. That clears it up a little. The current scope is part of
the VM internal state and compilers need to generate state
change instructions if they use lexicals.
Yes. More to the point only if they need to have a new set of lexicals.
We'll probably have scopeless subs.
(Actually, I hope
they only need state change instructions if they need the
scope's symbol table...)
Just to check my understanding, Perl 6 will compile
{ bar { foo } blah }
into
newscope
bar
newscope
foo
exitscope
blah
exitscope
Something like that, yes.
What happens with:
goto FOO; { bar { FOO: foo } blah }
Is goto responsible for figuring out it has entered bar's
scope and setting the VM state so that the exitscopes are
properly balanced?
I'm not sure what we'll do in that situation. gotos into scopes might not
be allowed.
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Speaking of namespaces...
On Monday 10 September 2001 09:27 pm, Dan Sugalski wrote: Parse opcode_table. Sync up your source first, there have been some changes to the format in the last few hours. I'll wait on those changes before delving back into the assembler for the simplified instruction handling. -- Bryan C. Warnock [EMAIL PROTECTED]
Patch: assembler deferred output
Following patch defers output of opcode until the end of an error-free run.
Also introduces a primitive '-c' option to allow checking of assembly only
(a la Perl).
Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.6
diff -u -r1.6 assemble.pl
--- assemble.pl 2001/09/10 21:26:08 1.6
+++ assemble.pl 2001/09/11 01:45:34
@@ -5,6 +5,11 @@
use strict;
my(%opcodes, %labels);
+my ($output, $opt_c);
+if (@ARGV and $ARGV[0] eq -c) {
+shift @ARGV;
+$opt_c = 1;
+}
my %pack_type;
%pack_type = (i = 'l',
@@ -52,14 +57,16 @@
# Now assemble
$pc = 0;
+my $line = 0;
while ($_ = shift @code) {
+$line++;
chomp;
s/,/ /g;
my ($opcode, @args) = split /\s+/, $_;
if (!exists $opcodes{lc $opcode}) {
- die No opcode $opcode;
+ die No opcode $opcode at line $line:\n $_\n;
}
if (@args != $opcodes{$opcode}{ARGS}) {
die wrong arg count--got . scalar @args. needed .
$opcodes{$opcode}{ARGS};
@@ -68,25 +75,27 @@
$args[0] = fixup($args[0])
if $opcode eq branch_ic and $args[0] =~ /[a-zA-Z]/;
-#if ($opcode eq eq_i_ic or $opcode eq lt_i_ic) {
- if ($opcode =~ /^(eq|ne|lt|le|gt|ge)_i_ic$/) {
+#if ($opcode eq eq_i_ic_ic or $opcode eq lt_i_ic_ic) {
+if ($opcode =~ /^(eq|ne|lt|le|gt|ge)_i_ic_ic$/) {
$args[2] = fixup($args[2]) if $args[2] =~ /[a-zA-Z]/;
$args[3] = fixup($args[3]) if $args[3] =~ /[a-zA-Z]/;
}
-if ($opcode eq if_i_ic) {
+if ($opcode eq if_i_ic_ic) {
$args[1] = fixup($args[1]) if $args[1] =~ /[a-zA-Z]/;
$args[2] = fixup($args[2]) if $args[2] =~ /[a-zA-Z]/;
}
-print pack l, $opcodes{$opcode}{CODE};
+$output .= pack l, $opcodes{$opcode}{CODE};
foreach (0..$#args) {
$args[$_] =~ s/^[INPS]?(\d+)$/$1/i;
my $type = $pack_type{$opcodes{$opcode}{TYPES}[$_]};
- print pack $type, $args[$_];
+ $output .= pack $type, $args[$_];
}
$pc += 1+@args;
}
+print $output unless (defined $opt_c and $opt_c);
+
sub fixup {
my $l = shift;
die Unknown label $l unless exists $labels{$l};
@@ -100,10 +109,10 @@
return $constants{$s} = $#constants;
}
-sub emit_magic { print pack($pack_type{i}, 0x13155a1) }
+sub emit_magic { $output .= pack($pack_type{i}, 0x13155a1) }
# Dummy for now.
-sub emit_fixup_section { print pack($pack_type{i}, 0) }
+sub emit_fixup_section { $output .= pack($pack_type{i}, 0) }
sub emit_constants_section {
# First, compute how big it's going to be.
@@ -116,17 +125,17 @@
}
$size += $sizeof_packi if @constants; # That's for the number of
constants
-print pack($pack_type{i}, $size);
+$output .= pack($pack_type{i}, $size);
return unless @constants; # Zero means end of segment.
# Then spit out how many constants there are, so we can allocate
-print pack($pack_type{i}, scalar @constants);
+$output .= pack($pack_type{i}, scalar @constants);
# Now emit each constant
for (@constants) {
-print pack($pack_type{i},0) x 3; # Flags, encoding, type
-print pack($pack_type{i},length($_)); # Strlen followed by that
many bytes.
-print $_;
-print \0 x (length($_) % $sizeof_packi); # Padding;
+$output .= pack($pack_type{i},0) x 3; # Flags, encoding, type
+$output .= pack($pack_type{i},length($_)); # Strlen followed by
that many bytes.
+$output .= $_;
+$output .= \0 x (length($_) % $sizeof_packi); # Padding;
}
}
--
Bryan C. Warnock
[EMAIL PROTECTED]
Re: Patch to assembler/disassembler + parrot asm inconsistancies
At 07:25 PM 9/10/2001 -0400, Bryan C. Warnock wrote: I think Dan mentioned this, but it looks like the suffixes can be derived from the args being passed in. That would greatly simply the assembler to just the function names: set, eq, add, branch. Were there problems with the scheme, is someone working on it, or did it fall through the cracks? (I'm very much in favor of such a change, and will pick it up if no one else is working on it.) No, I dont' think so, and yes, respectively. (Or, rather, we did the easy literal stuff first and planned on smartening up the assembler later. It's in the TODO even... :) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Patch to assembler/disassembler + parrot asm
On Mon, 2001-09-10 at 19:54, Dan Sugalski wrote:
At 07:45 PM 9/10/2001 -0500, Brian Wheeler wrote:
If eq_i_ic is really treated as /eq(_i)+_ic/ then this code still
doesn't work:
eq_i_ic I1,I2,NEXT,DONE
because that'd be like eq_i_i_ic_ic, right?
Right. But don't forget, I screwed up the eq op--it ought to have a single
destination. :)
DOH! That's the trick :)
I assume that opcodes aren't going to have variable arguments at this level,
so there should be a one-to-one mapping between function and opcode, right?
Each opcode number has a single function, yes. The same high-level
opcode, for example eq or add, might map to two or more different 'real'
opcodes based on the types of the args. There won't be any runtime
morphing--it's more The assembler sees the first arg of foo as a numberic
register and the second as a constant, so it must be foo_n_nc.
A thought (though gross): if we restrict mneumonics to not use the
underscore,
then anything after _ can be the op signature.
Too gross. We don't need to go there. :)
Just checking.
Also, doing it this way takes out the special cases for the comparison and
jump ops: the fixups are known to be done with things that have type 'a'
The jump ops will be easy to figure--either they'll take a register, a
constant number, or a label. We don't allow labels that could be confused
with registers. (No I0: anywhere...)
I've had more thoughts about my first patch. The case issue isn't an
issue since it only touches the generation tools, not the C code that's
generated (at least, not directly).
It also provides the additional information needed to let the assembler
choose the correct opcode, and the disassembler to dump things nicely :)
I've also fixed up the supporting tools. As a test case, I rebuilt
test_prog, assembled test.parm, ran it and dissassembled it. Looks for
for that one, at least :)
Please consider this new patch.
Brian
Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.6
diff -u -r1.6 assemble.pl
--- assemble.pl 2001/09/10 21:26:08 1.6
+++ assemble.pl 2001/09/11 02:02:15
@@ -9,7 +9,16 @@
my %pack_type;
%pack_type = (i = 'l',
n = 'd',
- );
+ );
+
+my %real_type=('i'='i',
+ 'n'='n',
+ 'N'='i',
+ 'I'='i',
+ 'S'='i',
+ 's'='i',
+ 'D'='i');
+
my $sizeof_packi = length(pack($pack_type{i},1024));
open GUTS, interp_guts.h;
@@ -26,8 +35,11 @@
s/^\s+//;
next unless $_;
my ($name, $args, @types) = split /\s+/, $_;
+my @rtypes=@types;
+@types=map { $_ = $real_type{$_}} @types;
$opcodes{$name}{ARGS} = $args;
$opcodes{$name}{TYPES} = [@types];
+$opcodes{$name}{RTYPES}=[@rtypes];
}
my $pc = 0;
@@ -65,23 +77,17 @@
die wrong arg count--got . scalar @args. needed .
$opcodes{$opcode}{ARGS};
}
-$args[0] = fixup($args[0])
-if $opcode eq branch_ic and $args[0] =~ /[a-zA-Z]/;
-
-#if ($opcode eq eq_i_ic or $opcode eq lt_i_ic) {
-if ($opcode =~ /^(eq|ne|lt|le|gt|ge)_i_ic$/) {
-$args[2] = fixup($args[2]) if $args[2] =~ /[a-zA-Z]/;
-$args[3] = fixup($args[3]) if $args[3] =~ /[a-zA-Z]/;
-}
-if ($opcode eq if_i_ic) {
-$args[1] = fixup($args[1]) if $args[1] =~ /[a-zA-Z]/;
-$args[2] = fixup($args[2]) if $args[2] =~ /[a-zA-Z]/;
-}
-
print pack l, $opcodes{$opcode}{CODE};
foreach (0..$#args) {
- $args[$_] =~ s/^[INPS]?(\d+)$/$1/i;
- my $type = $pack_type{$opcodes{$opcode}{TYPES}[$_]};
+ my($rtype)=$opcodes{$opcode}{RTYPES}[$_];
+ my($type)=$opcodes{$opcode}{TYPES}[$_];
+ if($rtype eq I || $rtype eq N || $rtype eq P || $rtype eq S) {
+ # its a register argument
+ $args[$_]=~s/^[INPS](\d+)$/$1/i;
+ } elsif($rtype eq D) {
+ # a destination
+ $args[$_]=fixup($args[$_]);
+ }
print pack $type, $args[$_];
}
$pc += 1+@args;
Index: disassemble.pl
===
RCS file: /home/perlcvs/parrot/disassemble.pl,v
retrieving revision 1.3
diff -u -r1.3 disassemble.pl
--- disassemble.pl 2001/09/10 21:45:33 1.3
+++ disassemble.pl 2001/09/11 02:02:16
@@ -8,14 +8,25 @@
my(%opcodes, @opcodes);
-my %unpack_type;
-%unpack_type = (i = 'l',
- n = 'd',
- );
+
+my %unpack_type = (i = 'l',
+ I = 'l',
+ n = 'd',
+ N = 'l',
+ D = 'l',
+ S = 'l',
+ s = 'l',
+ );
my %unpack_size = (i = 4,
n = 8,
+ I = 4,
+ N = 4,
+ D = 4,
+ S = 4,
+ s = 4,
);
+
open GUTS,
Re: Patch to assembler/disassembler + parrot asm inconsistancies
On Mon, 2001-09-10 at 20:52, Dan Sugalski wrote:
At 07:25 PM 9/10/2001 -0400, Bryan C. Warnock wrote:
I think Dan mentioned this, but it looks like the suffixes can be derived
from the args being passed in. That would greatly simply the assembler to
just the function names: set, eq, add, branch.
Were there problems with the scheme, is someone working on it, or did it
fall through the cracks? (I'm very much in favor of such a change, and will
pick it up if no one else is working on it.)
No, I dont' think so, and yes, respectively. (Or, rather, we did the easy
literal stuff first and planned on smartening up the assembler later. It's
in the TODO even... :)
Hint, Nudge, Wink: the last patch I sent that hits on the assembler
should make it very easy to add better assembly checking
For example, register checking could be done like this:
if($rtype eq I || $rtype eq N || $rtype eq P || $rtype eq S) {
# its a register argument
if($args[$_]=~m/^[INPS](\d+)$/) {
my($arg_num)=$1;
if($arg_num 32) {
# bad register number
} else {
$args[$_]=$arg_num;
}
} else {
# non-register being used!
}
} ...
Brian
Another Patch...
This patch (which is pretty big) does:
* Changes the opcode_table file to provide additional information about
the operands. Case shouldn't be a problem since that data never becomes
a C symbol [this is pretty much as before]
* Padding errors solved: assemble.pl and bytecode.c were padding the
constants incorrectly. It should have been 4-(size % 4), not just (size
% 4). It is now fixed in both places.
* assembler has less special cases, and should be easier to hang error
checking on
* disassembler dumps constant table and the format is a bit prettier,
including register names, etc. Test2.pbc dumps as this:
# Constants: 1 entries (32 bytes)
# ID FlagsEncoding Type Size Data
: 000b Hello World
# Code Section
: set_i_ic I2, 1
000c: set_i_ic I1, 0
0018: set_s_sc S1, [string ]
0024: eq_i_ic I1, I2, 0060, 0038
0038: length_s_i S1, I1
0044: print_s S1
004c: chopn_s_ic S1, 1
0058: branch_ic0024
0060: end
Let me know what you guys think!
Brian
[Crap, there's some wordwrapping below. Too bad you can plug emacs into
evolution :) ]
Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.6
diff -u -r1.6 assemble.pl
--- assemble.pl 2001/09/10 21:26:08 1.6
+++ assemble.pl 2001/09/11 03:14:32
@@ -9,7 +9,16 @@
my %pack_type;
%pack_type = (i = 'l',
n = 'd',
- );
+ );
+
+my %real_type=('i'='i',
+ 'n'='n',
+ 'N'='i',
+ 'I'='i',
+ 'S'='i',
+ 's'='i',
+ 'D'='i');
+
my $sizeof_packi = length(pack($pack_type{i},1024));
open GUTS, interp_guts.h;
@@ -26,8 +35,11 @@
s/^\s+//;
next unless $_;
my ($name, $args, @types) = split /\s+/, $_;
+my @rtypes=@types;
+@types=map { $_ = $real_type{$_}} @types;
$opcodes{$name}{ARGS} = $args;
$opcodes{$name}{TYPES} = [@types];
+$opcodes{$name}{RTYPES}=[@rtypes];
}
my $pc = 0;
@@ -65,23 +77,17 @@
die wrong arg count--got . scalar @args. needed .
$opcodes{$opcode}{ARGS};
}
-$args[0] = fixup($args[0])
-if $opcode eq branch_ic and $args[0] =~ /[a-zA-Z]/;
-
-#if ($opcode eq eq_i_ic or $opcode eq lt_i_ic) {
-if ($opcode =~ /^(eq|ne|lt|le|gt|ge)_i_ic$/) {
-$args[2] = fixup($args[2]) if $args[2] =~ /[a-zA-Z]/;
-$args[3] = fixup($args[3]) if $args[3] =~ /[a-zA-Z]/;
-}
-if ($opcode eq if_i_ic) {
-$args[1] = fixup($args[1]) if $args[1] =~ /[a-zA-Z]/;
-$args[2] = fixup($args[2]) if $args[2] =~ /[a-zA-Z]/;
-}
-
print pack l, $opcodes{$opcode}{CODE};
foreach (0..$#args) {
- $args[$_] =~ s/^[INPS]?(\d+)$/$1/i;
- my $type = $pack_type{$opcodes{$opcode}{TYPES}[$_]};
+ my($rtype)=$opcodes{$opcode}{RTYPES}[$_];
+ my($type)=$opcodes{$opcode}{TYPES}[$_];
+ if($rtype eq I || $rtype eq N || $rtype eq P || $rtype eq S) {
+ # its a register argument
+ $args[$_]=~s/^[INPS](\d+)$/$1/i;
+ } elsif($rtype eq D) {
+ # a destination
+ $args[$_]=fixup($args[$_]);
+ }
print pack $type, $args[$_];
}
$pc += 1+@args;
@@ -112,7 +118,10 @@
for (@constants) {
$size += 4*$sizeof_packi;
$size += length($_);
-$size += length($_) % $sizeof_packi; # Padding
+ my($pad)=length($_) % $sizeof_packi;
+ if($pad) {
+ $size+=$sizeof_packi-$pad;
+ }
}
$size += $sizeof_packi if @constants; # That's for the number of
constants
@@ -127,6 +136,9 @@
print pack($pack_type{i},0) x 3; # Flags, encoding, type
print pack($pack_type{i},length($_)); # Strlen followed by that
many bytes.
print $_;
-print \0 x (length($_) % $sizeof_packi); # Padding;
+ my $pad=(length($_) % $sizeof_packi);
+ if($pad) {
+ print \0 x ($sizeof_packi-(length($_) % $sizeof_packi)); #
Padding;
+ }
}
}
Index: bytecode.c
===
RCS file: /home/perlcvs/parrot/bytecode.c,v
retrieving revision 1.4
diff -u -r1.4 bytecode.c
--- bytecode.c 2001/09/10 21:47:26 1.4
+++ bytecode.c 2001/09/11 03:14:33
@@ -79,6 +79,7 @@
IV encoding = GRAB_IV(program_code);
IV type = GRAB_IV(program_code);
IV buflen = GRAB_IV(program_code);
+ int pad;
len -= 4 * sizeof(IV);
@@ -87,9 +88,11 @@
len -= buflen;
/* Padding */
-if (buflen % sizeof(IV)) {
-len -= buflen % sizeof(IV);
-(char*)*program_code += buflen % sizeof(IV);
+ pad=buflen % sizeof(IV);
+ if(pad) {
+ pad=sizeof(IV)-pad;
+ len -= pad;
+ (char*)*program_code += pad;
}
num--;
if (len 0 ||
RE: Math functions? (Particularly transcendental ones)
At 10:58 AM 9/10/2001 -0700, David Whipp wrote: Dan Sugalski wrote: Okay, I'm whipping together the fancy math section of the interpreter assembly language. I've got: [...] Can anyone think of things I've forgotten? It's been a while since I've done numeric work. I'm not sure where this belongs, but I'd really like to have a usage model for some of the edges of arithmetic. For example, it should be possible to enable/disable overflow and underflow exceptions. Basically, Perl5 should be IEE754 compliant; and it should support the (optional) traps. It would also nice to have a saturation-on-overflow mode/type. I'd intended the basic math ops on floats and ints (the ones in I and N registers) to ignore over and underflow stuff, or potentially throw exceptions, though there's no exception code at the moment. For math ops on variables, I'd intended they catch the exceptions and handle upgrading as appropriate. (The assumption being that the compiler would generate the low-level int/float code and make sure things don't over/underflow. I'm thinking that was probably a naive thought... :) If you have this type of stuff for floats; it'd be consistant to have it for integers, too. Yep. For variable operations we'd need it certainly, to catch cases where we need to go to the bigint format. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Math functions? (Particularly transcendental ones)
Uri Guttman we are planning automatic over/underflow to bigfloat. so there is no need for traps. they could be provided at the time of the conversion to big*. OK. But will Perl support signaling and non-signaling NANs? I don't think we should go for automatic overflow/underflow between float and bigfloat. The float exception (overflow, underflow, inexact, divide zero, ...) is very difficult to handle. Using Unix signal is expensive and very platform-specific (lots of ucontext issues). Since C language does not support floating-point signal, we may use some assembly code to handle it, it will be porting nightmare. Since most of floating-point assumes IEEE-semantics, taking automatic float/bigfloat will change this assumption significantly. It may a lot of code and algorithm. I think it is safer just to provide a BigDecimal class for developers to use, and keep the basic float semantics (close to 64-bit IEEE-754 if possible). Hong
RE: Math functions? (Particularly transcendental ones)
At 02:12 PM 9/10/2001 -0700, Hong Zhang wrote: Uri Guttman we are planning automatic over/underflow to bigfloat. so there is no need for traps. they could be provided at the time of the conversion to big*. OK. But will Perl support signaling and non-signaling NANs? I don't think we should go for automatic overflow/underflow between float and bigfloat. Not for N registers, no. Perl's standard scalar variable will do this, though. The float exception (overflow, underflow, inexact, divide zero, ...) is very difficult to handle. That's why we wrap it in a generic macro and leave it for the individual ports to handle. Using Unix signal is expensive and very platform-specific (lots of ucontext issues). Since C language does not support floating-point signal, we may use some assembly code to handle it, it will be porting nightmare. Not if we do it right to start. Yes, there may be snippets of assembly in solaris.c/vms.c/linux.c/whatever.c, but that's fine. We can use a boring test comparison as a generic replacement on platforms people don't want to use a specific one on. Since most of floating-point assumes IEEE-semantics, taking automatic float/bigfloat will change this assumption significantly. Most people I know that use floating point numbers don't have any idea that there are well-defined IEEE semantics, let alone what they are. Some folks are, and for them we'll make sure you can avoid leaving IEEE floats. Of course, that's as much an argument for automatically going straight to bigfloats rather than going to native floats, since if people generally have no idea what the errors inherent in IEEE floats are they probably ought not use them. That's something to take up with Larry, though. It may a lot of code and algorithm. I think it is safer just to provide a BigDecimal class for developers to use, and keep the basic float semantics (close to 64-bit IEEE-754 if possible). IEEE floats suck. (I've got an amazingly bad opinion of a lot of widely-accepted computer practice, don't I? :) They're an OK option for what they are, and the hardware speed support is nice, but let's face it, they're a compromise with adequate characteristics, and the design compromises are usually the wrong ones (with the single exception of speed) for what most people do with floats in perl. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Math functions? (Particularly transcendental ones)
DW == David Whipp [EMAIL PROTECTED] writes: DW Dan Sugalski wrote: Okay, I'm whipping together the fancy math section of the interpreter assembly language. I've got: DW [...] Can anyone think of things I've forgotten? It's been a while since I've done numeric work. DW I'm not sure where this belongs, but I'd really like to have DW a usage model for some of the edges of arithmetic. For example, DW it should be possible to enable/disable overflow and underflow DW exceptions. Basically, Perl5 should be IEE754 compliant; and it DW should support the (optional) traps. It would also nice to have DW a saturation-on-overflow mode/type. we are planning automatic over/underflow to bigfloat. so there is no need for traps. they could be provided at the time of the conversion to big*. DW If you have this type of stuff for floats; it'd be consistant to DW have it for integers, too. overflow to bigint is also planned. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Search or Offer Perl Jobs -- http://jobs.perl.org
Parrot 0.0.1 is released.
Because the game of hide-and-seek was still going on, it took Edmund and Lucy some time to find the others. But when at last they were all together (which happened in the long room, where the suit of armour was) Lucy burst out: Peter! Susan! It's all true. Edmund has seen it too. There is a country you can get to through the wardrobe. Edmund and I both got in. We met one another in there, in the wood. Go on, Edmund; tell them all about it. - The Lion, The Witch and the Wardrobe, CS Lewis I suppose (unlike Edmund did) I should tell you all about it. What we're releasing today is a very, very early alpha of the Parrot interpreter. At the moment, we have support for some simple operations on integer, floating point and string registers, and the ability to read in and execute bytecode. We also have an assembler which can generate bytecode output from Parrot assembly. You can get the source tarball in (currently) two different ways: From CPAN: http://www.cpan.org/authors/id/S/SI/SIMON/parrot-0.0.1.tar.gz http://www.cpan.org/src/parrot-0.0.1.tar.gz (once the mirrors have updated) From CVS: See the Parrot CVS home page at http://cvs.perl.org/ Once you've unpacked parrot, you should be able to make test_prog, and use the Parrot assembler to turn assembly into bytecode: make test_prog perl assemble.pl test.pasm test.pbc ./test_prog test.pbc perl assemble.pl test2.pasm test2.pbc ./test_prog test2.pbc The first test program will add some numbers together, count to 10,000,000, and tell you how long it took; the second test program will print a familiar greeting. In the next email, coming in a couple of minutes, I'll outline two areas where I really, really need some patches before we go much further; you should also note that Parrot has a bug/request tracking system at http://parrotbugs.develooper.com/ which will be filled with some more things that I'd like people to take a look at. Patches should be sent to the perl6-internals mailing list, where I'll take a look at them and apply them to the CVS tree. As time goes by, people who regularly submit good patches will be given committer access to the tree, and can help me out applying other patches from the list. IMPORTANT! Please note that we haven't decided the final license for Parrot yet. You currently receive Parrot under the same terms as Perl 5: your choice of either the Artistic or General Public Licenses. Have fun, Simon -- set_s_sc S1, Just Another Parrot Hacker, print_s S1
