Re: Opcode Dispatch
On Monday 06 August 2001 09:08 am, Bryan C. Warnock wrote: > It could be that part of the "fixup" is to convert from bytes to wider > ops, or something similar. If that's the case, I can patch the code and > rerun it. Okay. I rewrote the code from scratch. (Rev 2 is always better anyway.) Same machines as before. I followed Dan's recipe (for the most part). The opcodes are now 32 bits wide, and each opcode takes 0, 1, or 2 arguments. I tested with 512, 1024, 2048, and 8192 opcodes (all contiguous) in a single table. I did not do any sort of context switching between multiple tables. The 8192-* tests did not complete, and I've scrapped them. (As you'll see, some of the tests were insane, and gcc was having fits attempting to optimize.) The 2048-* tests did not complete on Solaris. (The tests ran for about seven hours.) I've reported the partial results, and you should be able to extrapolate the remainder. I tested a full table lookup dispatch, a full switch dispatch, and a partial switch / the rest lookup dispatch. The full switch had both a normal and an inlined NO-OP opcode variant. The partial switch would switch on 32, 128, or 256 opcodes (all contiguous), and had normal, inlined NO-OP, and ully inlined switch variants. Tests were run with both gcc's debugging '-g' and optimization '-O2' flags. Infortunately, I didn't time the actual compilation of each test. Some of them were taking quite a while, and that, of course, should come into play. Each data set consisted of 40,000 opcodes (randomly distributed between opcode 2 and opcode[-1]) and their arguments, appended with a single opcode 1 (program termination). The data was interspersed with 7% NO-OP opcodes. This "program" was looped through 5000 times. A summary of results: Full switches are right out, and will not be tested again. They were the slowest of the constructs, and usually by a lot. For Linux/x86, lookup consistently faster with no optimizations. With optimizations, lookup was the fastest with the smallest number of opcodes. As more and more opcodes were added, some of the inlined partial switches were just as efficient as a lookup. For Solaris/Sparc, the inlined-variant partial switches were fastest with the smaller number of opcodes and case statements. As the number of opcodes increased, lookup became slightly faster with optimized code, but consistently slower with the debug code. The complete results can be found at http://members.home.com/bcwarno/Perl6/opcode_test_results.txt -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Draft assembly PDD
On Mon, 06 Aug 2001 21:55:07 -0400, Dan Sugalski wrote: >>But I do not agree that calculated jumps should be done in such a hard >>way. > >Nothing hard about it, really. I was referring to Hong Zhang's proposal, not yours. -- Bart.
Re: properties, revisited
> Damian, > You mentioned in E2 that the chomped property relies on the insep > property of the filehandle (formerly $/). Can I extrapolate that >$. >$, >$\ >$| > will also be properties on filehandles? (How about >$" > for arrays?) It's not yet clear to me whether these will be properties on filehandles, or attributes of them (or indeed, whether there will be any real difference between the two). That's really up to Larry. But, yes, I would fully expect that the global punctuation I/O control variables will become attributes/properties/traits of individual filehandles. Damian
Re: properties, revisited
> More questions regarding the new 'given when' construct.
More answers (modulo Larry :-)
> 1) Is a 'when' clause required? Is it:
>
> [ LABEL: ] given ( expr_1 ) {
>when expr_2 : block
>[ when expr_3 : block ...]
>expr_n [;]
> }
>
> or
>
> [ LABEL: ] given ( expr_1 ) {
>[ when expr_2 : block ...]
>expr_n [;]
> }
Not required. It's:
[ LABEL: ] given ( expr_1 ) {
[statement ; ...]
[statement]
}
A C statement is just a particular kind of statement.
> 2) In expressions 2 through n-1 - the equivalent to 'case' - you
>may refer to the return value of expression 1 with $^_. Does
>this imply that expression 1 will always (and only) be evaluated
>in scalar context? If not, can you mix contexts across 'when'
>clauses? Is the value of $^_ then a reference to the return
>value?
The C expression is evaluated in scalar context.
> 3) Can you refer to $^_ within expression n - the equivalent to 'default:'?
> given ( a() ) {
>print $^_; # No when clause? See #1
> }
$^_ isn't an alias for the C's expression.
It's a higher-order function placeholder
(see: http://www.yetanother.org/damian/Perl5+i/higherorder.html)
So the answer is "no".
> 4) Can you refer to $^_ within the code blocks of each 'when' clause?
> given ( a() ) {
> when $^_ == 1 : { foo($^_) }
> when $^_ == 2 : { bar( 5 + $^_ ) }
> when $^_ == 3 : { ++$^_ and print $^_ } # Mutable? See #5
> }
No. See the previous answer.
If the gvien value is needed within the block, the most likely mechanism
would be:
given ( my $a = a() ) {
when $^_ == 1 : { foo($a) }
when $^_ == 2 : { bar( 5 + $a ) }
when $^_ == 3 : { ++$a and print $a } # Mutable? See #5
}
> 5) Is $^_ an alias, reference (See #2), or a copy of the return value of
> expression 1, and is it mutable? Does it have the appropriate magic and
> overloading capabilities?
None of the above. See above.
> 6) How many times is expression 1 evaluated?
Once.
> $a = 0;
> given ( ++$a ) {
> when $^_ > 5 : { #foo }
> when $^_ > 4 : { #bar }
> when $^_ > 3 : { #baz }
> #foobar
> }
>
> I would expect that $a would equal '1' after #foobar executed. But if
> multiple contexts are allowed (see question 2), how would
N/A.
> 7) The 'when' blocks are not fall-through, a la C's switch statement. You
> can obtain a similar result by invoking 'next' within the 'when' block.
>
> Is this regardless of whether expr2 would have also evaluted true? (IOW,
> does it truly jump to the next block?) If not, does it jump to the
> expression after that (if it exists) and try again, or does it default
> expression (since the original next expression evaluated false)?
A C within a C's block causes control to jump to the next
statement in the innermost surrounding 's block.
If that is a C statement, the C test is then evaluated as normal.
> 8) Is the order of evaluation guaranteed? (I assume so, but just thought
> I'd check.)
I certainly hope so! ;-)
> 9) It has a lexical construct similar to a conditional block, so that
> lexical variables declared in the 'given' expression are within the inner
> scope, correct?
Correct.
> 10) I've already asked Damian this question on the side, but I'll
> repeat (and expand) it here, to give me an even ten. Should it
> be a single default expression, multiple default expressions,
> or a default block?
Any of the above. A C block is just a block. A C statement
is just a statement. You can put any statement inside any block, so you
can put both C and non-C statements inside a C (in any
sequence and multiplicity you like).
Damian
Re: properties, revisited
Dan suggested:
> The syntax for variable and value properties are going to be different, I
> think, I just can't remember what it's going to be. (I think the colon's
> involved, but isn't it always?)
I think you're now channelling my de specula, not Larry's de jure. :-)
In A2, Larry stated that both variable and value properties would be
specified using the C keyword.
Subsequently, I drafted a private proposal that separated the property
notion into two distinct semantic concepts with distinct syntaxes. That
proposal was sent only to Larry, but I will now reproduce it here to
show my current thinking on the subject.
Damian
---cut---cut---cut---cut---cut--
It seems that my property concept is becoming a little chunky.
So let me try again...
Suppose variables and subroutines had compile-time "traits"
whilst values had run-time "properties".
Subroutine and variable traits are specified in declarations via a colon
(i.e. they're colonic adverbs on the C, C, C declarator, whilst
remaining
syntactically near-as-dammit to Perl 5 attributes):
my $foo : constant Wheel(4) Drive('transmission') = 'RV';
my %bar : persistent;
sub marine : Wet lvalue {...}
At run-time, traits may be read-accessed via a pseudo-method call:
if (%bar.persistent) { ... }
print "$foo.Drive() to all $foo.Wheel() wheels\n";
or (unambiguously) via the C built-in, which returns a hashref:
if (trait(%bar){persistent}) { ... }
my %t = trait $foo;
print "%t{Drive} to all %t{Wheel} wheels\n";
Value properties are set at run-time via an C:
return 0 is true;
%bar{Jonah} is Called('son of fish food');
and may be accessed via a pseudo-method call:
if ($foo.true) { ... }
print "His nickname was ", %bar{Jonah}.Called;
or unambiguously via the C built-in, which returns a hashref:
if (prop($foo){true}) { ... }
print "His nickname was $(prop(%bar{Jonah}){Called})\n";
So we now have:
* backwards compatibility with Perl 5 attributes
* no compile-time C vs run-time C confusion
* no variable vs value ambiguity
* polymorphic access to variable or value annotations (via methods)
* monomorphic access to variable or value annotations (via builtins)
and, as a bonus:
* the ability to put a trait specifier *anywhere* in a declaration
(because it's an adverb), and
* the ability to use both types of annotation in one statement:
my $threshold : constant = 0 is true;
my $threshold = 0 is true : constant;
Semi-OT: Good compiler book?
I'm going on vacation soon, and I'd like to get a good book on writing compilers--hopefully one that will help me when we actually start coding Perl 6. Any suggestions? I have no formal education on compilers, and I only know C, C++ and Perl (duh). (If this is too off-topic, let me know.) Thanks, --Brent Dax [EMAIL PROTECTED]
RE: properties, revisited
> # >my $foo is const = 0 is true;
> # >
> # > $foo has the property const, while the value 0 in $foo has
> # > the property true.
> #
> # So, if I do
> #
> # my $foo is constant = new Counter(0);
> # $foo->increment # OK
>
> I think so.
Yep. Except the property name is likely to just be C.
> # my $bar = new Counter(0) is constant;
> # $bar->increment; #error
>
> Maybe. I think that would depend on the Counter class's implementation
The "constant" property is applied to the particular reference to the
object that was returned by C and stored in $bar (*not* to the object
itself!) Hence, the C method would have to be
something like the following, in order to respect it:
sub increment ($self) {
croak "Can't increment constant Counter" if $self.constant;
}
> # However, if I do
> #
> # %foo is constant = (a=>1, b=>$foo);
> #
> # are only the keys contant; or both the keys and values.
>
> Keys and values, I imagine.
Probably.
Damian
Re: new syntax idea: eval "..."o;
David L. Nicol wrote:
> eval ${code}o;
Another brilliant idea from David Nicol!
However, I'm not keen on the syntax.
I'd rather see a different keyword. I'm thinking "eval1",
but I'm not very creative. :-/
--
John Porter
Science class should not end in tragedy.
That could be interesting ... CPAN? and why there is no C/C++ CPAN
http://www.kuro5hin.org/story/2001/6/8/11126/34098
TPC5 Onion slides
Hi, I can't find Larry's slides from TPC5 online anywhere. Is it just me or what? :) - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than 100M impressions per day, http://valueclick.com
Re: Semi-OT: Good compiler book?
The Dragon Book is (AFAIK) still considered the definitive book on the subject. It's called that because it has (or at least, had, for the edition that I bought) a red dragon on the cover. The official title is: Compilers : Principles, Techniques, and Tools by Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman (Contributor) ISBN: 0201100886 You can get it from Fatbrain: http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0201100886&vm= Dave On Tue, 7 Aug 2001, Brent Dax wrote: > I'm going on vacation soon, and I'd like to get a good book on writing > compilers--hopefully one that will help me when we actually start coding > Perl 6. Any suggestions? I have no formal education on compilers, and > I only know C, C++ and Perl (duh). > > (If this is too off-topic, let me know.) > > Thanks, > --Brent Dax > [EMAIL PROTECTED] > >
Re: Semi-OT: Good compiler book?
>The official title is: > >Compilers : Principles, Techniques, and Tools >by Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman (Contributor) >ISBN: 0201100886 > >You can get it from Fatbrain: > >http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0201100886&vm= > or cheaper at Bookpool http://www.bookpool.com/.x/6jipibmev1/sm/0201100886 -- -mark koopman WebSideStory 10182 Telesis Court San Diego CA 92121 858-546-1182 ext 318 -- -mark koopman WebSideStory 10182 Telesis Court San Diego CA 92121 858-546-1182 ext 318
Re: Semi-OT: Good compiler book?
At 06:06 PM 8/7/2001 -0700, Dave Storrs wrote: >The Dragon Book is (AFAIK) still considered the definitive book on the >subject. It's called that because it has (or at least, had, for the >edition that I bought) a red dragon on the cover. > >The official title is: > >Compilers : Principles, Techniques, and Tools > by Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman (Contributor) >ISBN: 0201100886 Be aware that the Dragon Book has a few little quirks, and is definitely an intro book. Compiler technology's progressed quite a bit past what's presented in there. Unfortunately all the references I have for alternatives really require what the Dragon Book teaches as a foundation. (It's a bit dodgy going without it) >On Tue, 7 Aug 2001, Brent Dax wrote: > > > I'm going on vacation soon, and I'd like to get a good book on writing > > compilers--hopefully one that will help me when we actually start coding > > Perl 6. Any suggestions? I have no formal education on compilers, and > > I only know C, C++ and Perl (duh). > > > > (If this is too off-topic, let me know.) > > > > Thanks, > > --Brent Dax > > [EMAIL PROTECTED] > > > > Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: new syntax idea: eval "..."o;
> David L. Nicol wrote:
> > eval ${code}o;
>
> Another brilliant idea from David Nicol!
>
> However, I'm not keen on the syntax.
> I'd rather see a different keyword. I'm thinking "eval1",
> but I'm not very creative. :-/
]- what about :
qe//;# qe{};
OR
qo//
Re: new syntax idea: eval "..."o;
On Tue, 7 Aug 2001 09:27:43 -0400, John Porter wrote:
>David L. Nicol wrote:
>> eval ${code}o;
>
>Another brilliant idea from David Nicol!
Not really.
What I would like is an option to just *compile* a piece of perl code,
without executing it. This kinda works:
$coderef = eval "sub { $code }";
and currently (5.6.0) even if $code contains sub definitions; but it's
still just a hack.
--
Bart.
Re: properties, revisited
> There are a number of properties "built into" Perl 6. Nearly all of these > properties don't make sense across the board - eg, a scalar won't have a > dimension, a hash won't prompt, etc. > > So given the two different sets that you must consider (variable versus > value, and hash versus array versus scalar versus filehandle), are > properties that are meaningless for some section usable by the user? I would expect so, but Larry's MMV. Damian
Re: Draft assembly PDD
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> Not that tricky. (And no, those aren't regex variables. I'm having DS> LSI-11 Macro flashbacks here) >> >> wow, the macro-11 private/lexical labels! one of the very nice features >> of macro-11 that is worth stealing (if perl didn't already have loops :) DS> Yup. I plan on stealing it, more or less, for the parrot assembler. we do need macros at the assembler level. i actually imagine some masochists^Wexperimenters will write hand parrot^Wsantana code. there might even be a good use for it if the optimizor can't really tweak it right. so we will need many of the faetures that the classic macro assemblers had. i think the assembler could be written in perl(5) with no trouble. so here is a partial list of useful features: label support for sub calls, branching, etc. immediate values (constants, strings, etc.) macros with positional or named params, local label generation, conditionals (which execute when the macro is expanded), etc. DS> Parrot won't care--if you want to branch someplace, go for DS> it. It's your responsibility as a programmer (or programmer DS> writing code generators) to make sure that the destination's a DS> valid place to branch to. and having label support will make that easier. we don't want santana coders to count bytes to branch. this will require 2 passes which isn't a major problem >> and pdp-11 had BR and MOV op codes, not 'store' and 'branch'. DS> Sure, but then we don't have to wedge our opcode names into the DS> RAD-50 restricted character sets. (We'll be able to have opcode DS> names longer than 6 characters, too... :) nah, i say let's restrict all santana tokens to RAD-50. these young whippersnappers don't know how good they have it with long names and full character sets. 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
RE: Draft assembly PDD
On Mon, 6 Aug 2001, Dan Sugalski wrote: > No, he's right. Not dirtying cache lines is pretty much always faster than > dirtying them, and not twiddling with memory's faster than twiddling. And > unfortunately we can't really do fully platform-dependent code, since it'll > be the actual bytecode that'll ned to be different. Ok, I'll go back to lurking - I definitely don't have the education to try to argue the point. I've got some half-formed idea about a stack-based opcode set that compiles down to register references at runtime, but I'm definitely a few books short of articulate on this subject. Choose wisely then - if we want this thing to run well on the Palm and on the Athlon we'll have to! > We're actually doing the appropriate amount of optimization here. When > dealing with low-level constructs it's appropriate to consider low-level > effects and algorithms that handle low-level machinery. Lo tho we walk through the valley of the shadow of the JVM... Is anyone else nervous that we seem to be trying to replace GCC here? Is register allocation really something the Perl community has expertise in? -sam
Re: Draft assembly PDD
> "ST" == Sam Tregar <[EMAIL PROTECTED]> writes: ST> Lo tho we walk through the valley of the shadow of the JVM... Is ST> anyone else nervous that we seem to be trying to replace GCC here? ST> Is register allocation really something the Perl community has ST> expertise in? one more time: a software virtual machine is a very different beast than a real hardware cpu. we don't have the many cost and speed restrictions (breaking pipelines, branch prediction, out of order execution, etc.) that modern cpu's have. we have our own issues like switch vs. lookup, cache hits, loop speed, etc. the part about managing registers is not hard. that is very old compiler technology from the classic CISC machines which didn't have pipelines and wierd stuff. so this has nothing to do with replacing GCC or any other compiler or VM). this is just about santana (or parrot which i don't prefer as much) and its VM (which is what dan and co. are designing). 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
Re: Draft assembly PDD
At 12:41 PM 8/7/2001 -0400, Uri Guttman wrote: > > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: > > DS> Not that tricky. (And no, those aren't regex variables. I'm having > DS> LSI-11 Macro flashbacks here) > >> > >> wow, the macro-11 private/lexical labels! one of the very nice features > >> of macro-11 that is worth stealing (if perl didn't already have loops :) > > DS> Yup. I plan on stealing it, more or less, for the parrot assembler. > >we do need macros at the assembler level. i actually imagine some >masochists^Wexperimenters will write hand parrot^Wsantana code. Got it right the first time. Short of a decree from Larry, or some sort of summit decision between the dynamic language folks, Parrot Is It. And we'll definitely have folks hand-writing assembly code. Us, if nobody else--we'll need to do so for bootstrapping and testing reasons, if nothing else. >there >might even be a good use for it if the optimizor can't really tweak it >right. so we will need many of the faetures that the classic macro >assemblers had. i think the assembler could be written in perl(5) with >no trouble. > >so here is a partial list of useful features: > >label support for sub calls, branching, etc. Yup. >immediate values (constants, strings, etc.) Yup. >macros with positional or named params, local label generation, > conditionals (which execute when the macro is expanded), etc. Not sure about that. I know it's useful, but I'm not sure how useful relative to other things that need doing instead. (I many recant that once I start pounding out Parrot code...) > DS> Parrot won't care--if you want to branch someplace, go for > DS> it. It's your responsibility as a programmer (or programmer > DS> writing code generators) to make sure that the destination's a > DS> valid place to branch to. > >and having label support will make that easier. we don't want santana >coders to count bytes to branch. this will require 2 passes which isn't >a major problem Exactly. We can make multiple passes easily enough. Not like we're swapping to tape or anything here. > >> and pdp-11 had BR and MOV op codes, not 'store' and 'branch'. > > DS> Sure, but then we don't have to wedge our opcode names into the > DS> RAD-50 restricted character sets. (We'll be able to have opcode > DS> names longer than 6 characters, too... :) > >nah, i say let's restrict all santana tokens to RAD-50. these young >whippersnappers don't know how good they have it with long names and >full character sets. Heh. We can make all the ASCII folks as uncomfortable as the Unicode people. :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
RE: Draft assembly PDD
At 12:53 PM 8/7/2001 -0400, Sam Tregar wrote: >On Mon, 6 Aug 2001, Dan Sugalski wrote: > > > No, he's right. Not dirtying cache lines is pretty much always faster than > > dirtying them, and not twiddling with memory's faster than twiddling. And > > unfortunately we can't really do fully platform-dependent code, since it'll > > be the actual bytecode that'll ned to be different. > >Ok, I'll go back to lurking - I definitely don't have the education to try >to argue the point. I've got some half-formed idea about a stack-based >opcode set that compiles down to register references at runtime, but I'm >definitely a few books short of articulate on this subject. You can definitely go from a stack-based to register-based system--heck, it's what perl does now, after a fashion. :) Doing it efficiently's a different problem entirely, and it adds some extra inefficiencies to the process. You get a sort of impedence mismatch problem when you switch between stack & register forms, which you don't (as much) when going from register to register forms. >Choose wisely then - if we want this thing to run well on the Palm and on >the Athlon we'll have to! The Athlon's easy--we're in the "power to burn" category there. It's the Palm that's trickier. > > We're actually doing the appropriate amount of optimization here. When > > dealing with low-level constructs it's appropriate to consider low-level > > effects and algorithms that handle low-level machinery. > >Lo tho we walk through the valley of the shadow of the JVM... Is anyone >else nervous that we seem to be trying to replace GCC here? Me! Though being nervous is my job, I think. >Is register >allocation really something the Perl community has expertise in? This is an old, solved problem. There's literature that predates me in this arena. (Heck, I think there might be literature that predates Larry) It's not something the perl community per se has really ever needed to deal with, but that's because it's not really something that most communities need to deal with. There aren't all that many folks seriously writing compilers. (Whether this is a good thing or not is a separate issue) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Draft assembly PDD
At 11:10 AM 8/7/2001 +0200, Bart Lateur wrote: >On Mon, 06 Aug 2001 21:55:07 -0400, Dan Sugalski wrote: > > >>But I do not agree that calculated jumps should be done in such a hard > >>way. > > > >Nothing hard about it, really. > >I was referring to Hong Zhang's proposal, not yours. Ah, OK. I tend to get confused. :) Hong's proposal is dead-on for hardware, for that I have no doubt at all. Luckily (I think) we're not quite at that level, so we can layer on some useful abstractions and cut out a few opcode dispatches. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Opcode Dispatch
At 09:40 AM 8/7/2001 -0400, Bryan C. Warnock wrote: >On Monday 06 August 2001 09:08 am, Bryan C. Warnock wrote: > > It could be that part of the "fixup" is to convert from bytes to wider > > ops, or something similar. If that's the case, I can patch the code and > > rerun it. > >Okay. I rewrote the code from scratch. (Rev 2 is always better anyway.) >Same machines as before. > >I followed Dan's recipe (for the most part). The opcodes are now 32 bits >wide, and each opcode takes 0, 1, or 2 arguments. This is sweet--thanks. I think we might want to have some profiling runs once we're going and have platform hints as to which form of the core loop's best. If that works out OK, I'll be happy. ' BTW, can I get the source to the tests? I'd like to give them a whirl to see how the Alphas deal with the various alternatives. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Draft assembly PDD
At 11:55 PM 8/6/2001 -0400, Uri Guttman wrote: > > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: > > DS> Nothing hard about it, really. We'll see either: > > DS>branch $10 > > DS> or > > DS>store I12, $10 > DS>branch I12 > > DS> Not that tricky. (And no, those aren't regex variables. I'm having > DS> LSI-11 Macro flashbacks here) > >wow, the macro-11 private/lexical labels! one of the very nice features >of macro-11 that is worth stealing (if perl didn't already have loops :) Yup. I plan on stealing it, more or less, for the parrot assembler. >but I12 would have to be a labeled location for that to be legal. Parrot won't care--if you want to branch someplace, go for it. It's your responsibility as a programmer (or programmer writing code generators) to make sure that the destination's a valid place to branch to. >and pdp-11 had BR and MOV op codes, not 'store' and 'branch'. Sure, but then we don't have to wedge our opcode names into the RAD-50 restricted character sets. (We'll be able to have opcode names longer than 6 characters, too... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[Python-Dev] Intel's Open Runtime Platform (ORP) (fwd)
I don't think anyone mentioned this before here... -- Forwarded message -- Date: Mon, 6 Aug 2001 19:43:53 -0700 From: Neil Schemenauer <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: [Python-Dev] Intel's Open Runtime Platform (ORP) I just saw this while updating my Debian machine: Package: orp Description: Java VM and JIT from Intel Research Lab. ORP stands for Open Runtime Platform, which is an Intel(TM) Open Source research platform for investigating dynamic compilation and memory management technologies. The basic ORP system incorporates a fast code generating JIT (Just-In-Time) as well as an optimizing JIT. It also includes several GC (Garbage Collection) algorithms, ranging from a simple mark-sweep algorithm to an advanced train algorithm. Its available at http://intel.com/research/mrl/orp/ and is released under a BSD-like license. Neil ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev
Re: Opcode Dispatch
On Tuesday 07 August 2001 10:48 am, Dan Sugalski wrote: > BTW, can I get the source to the tests? I'd like to give them a whirl to > see how the Alphas deal with the various alternatives. http://members.home.com/bcwarno/Perl6/spool/opcode_test.tgz -- Bryan C. Warnock [EMAIL PROTECTED]
