Larry == Larry Wall [EMAIL PROTECTED] writes:
Larry : Nah, bytecode'll have an endianness marker at the top. If you
Larry : load in bytecode with the wrong endianness, the loader will
Larry : have to swap for you.
Larry Er. If they're not bytes, we can't call it bytecode.
Unless you want to
On Tue 29 May 2001 19:25, Dave Mitchell [EMAIL PROTECTED] wrote:
=item *
KR style for indenting control constructs: ie the closing C} should
line up with the opening Cif etc.
=item *
When a conditional spans multiple lines, the opening brace must line up
with the if or while, or be at
On Tue 29 May 2001 19:25, Dave Mitchell [EMAIL PROTECTED] wrote:
=head2 Portability
Related to extensibility is portability. Perl runs on many, many
platforms, and will no doubt be ported to ever more bizarre and obscure
ones over time. You should never assume an operating system,
Uri Guttman [EMAIL PROTECTED] writes:
DS The one handy thing about push and pop is you don't need to go
DS tracking the stack manually--that's taken care of by the push and
DS pop opcodes. They can certainly be replaced with manipulations of
DS a temp register and indirect register stores
KR style for indenting control constructs: ie the closing C} should
line up with the opening Cif etc.
=item *
When a conditional spans multiple lines, the opening brace must line up
with the if or while, or be at the end-of-line otherwise.
I certainly will not change existing
Uri Guttman [EMAIL PROTECTED] writes:
think of this as classic CISC code generation with plenty of registers
and a scratch stack. this is stable technology. we could even find a
code generator guru (i don't know any obvious ones in the perl6 world)
Classic CISC code generation taught us that
On Wed 30 May 2001 16:12, Dave Mitchell [EMAIL PROTECTED] wrote:
KR style for indenting control constructs: ie the closing C} should
line up with the opening Cif etc.
=item *
When a conditional spans multiple lines, the opening brace must line up
with the if or while, or be
On Wed, May 30, 2001 at 04:23:58PM +0200, H.Merijn Brand wrote:
On Wed 30 May 2001 16:12, Dave Mitchell [EMAIL PROTECTED] wrote:
KR style for indenting control constructs: ie the closing C} should
line up with the opening Cif etc.
=item *
When a conditional spans
At 04:23 PM 5/30/2001 +0200, H.Merijn Brand wrote:
But I know I'm rather alone on this, though I'm not just someone saying:
Cause that looks nice. I have several reasons for dong so and can defend
my stance.
Just to head off potential formatting/code style issues... (And this is
*not*
On Wed 30 May 2001 16:29, Graham Barr [EMAIL PROTECTED] wrote:
On Wed, May 30, 2001 at 04:23:58PM +0200, H.Merijn Brand wrote:
On Wed 30 May 2001 16:12, Dave Mitchell [EMAIL PROTECTED] wrote:
:::
But I know I'm rather alone on this, though I'm not just someone saying: Cause
that looks
At 02:08 PM 5/30/2001 +, Nick Ing-Simmons wrote:
Uri Guttman [EMAIL PROTECTED] writes:
think of this as classic CISC code generation with plenty of registers
and a scratch stack. this is stable technology. we could even find a
code generator guru (i don't know any obvious ones in the
On Wed 30 May 2001 16:37, Dan Sugalski [EMAIL PROTECTED] wrote:
At 04:23 PM 5/30/2001 +0200, H.Merijn Brand wrote:
But I know I'm rather alone on this, though I'm not just someone saying:
Cause that looks nice. I have several reasons for dong so and can defend
my stance.
Just to head off
Dan Sugalski [EMAIL PROTECTED] writes:
At 02:08 PM 5/30/2001 +, Nick Ing-Simmons wrote:
Classic CISC code generation taught us that CISC is a pain to code-gen.
(I am not a Guru but did design TMS320C80's RISC specifically to match
gcc of that vintage, and dabbled in a p-code for Pascal way
NI == Nick Ing-Simmons [EMAIL PROTECTED] writes:
NI Uri Guttman [EMAIL PROTECTED] writes:
think of this as classic CISC code generation with plenty of registers
and a scratch stack. this is stable technology. we could even find a
code generator guru (i don't know any obvious ones
NI == Nick Ing-Simmons [EMAIL PROTECTED] writes:
NI The overhead of op dispatch is a self-proving issue - if you
NI have complex ops they are expensive to dispatch.
but as someone else said, we can design our own ops to be as high level
as we want. lowering the number of op calls is the
Dave Mitchell [EMAIL PROTECTED] writes:
There's no reason why you can.t have a hybrid scheme. In fact I think
it's a big win over a pure register-addressing scheme. Consider...
Which was more or less my own position...
At the start of a new scope, the stack is extended by N to create a new
Dan Sugalski writes:
: Right, but in this case we have the advantage of tailoring the instruction
: set to the language, and given the overhead inherent in op dispatch we also
: have an incentive to hoist opcodes up to as high a level as we can manage.
We basically tried this experiment with
There's no reason why you can.t have a hybrid scheme. In fact I think
it's a big win over a pure register-addressing scheme. Consider...
The hybrid scheme may be a win in some cases, but I am not sure if it
worth the complexity. I personally prefer a strict RISC style opcodes,
mainly load,
Uri Guttman [EMAIL PROTECTED] writes:
NI == Nick Ing-Simmons [EMAIL PROTECTED] writes:
NI The overhead of op dispatch is a self-proving issue - if you
NI have complex ops they are expensive to dispatch.
but as someone else said, we can design our own ops to be as high level
as we want.
At 10:06 AM 5/30/2001 -0700, Hong Zhang wrote:
There's no reason why you can.t have a hybrid scheme. In fact I think
it's a big win over a pure register-addressing scheme. Consider...
The hybrid scheme may be a win in some cases, but I am not sure if it
worth the complexity. I personally
DS == Dan Sugalski [EMAIL PROTECTED] writes:
DS The size of the generated bytecode's likely not going to be
DS directly an issue in determining speed. (And we can't count on
DS keep the locals exclusively in the register set either, as
DS otherwise string eval won't be able to find
Larry Wall [EMAIL PROTECTED] writes:
Dan Sugalski writes:
1) The indentation should be all tabs or all spaces. No mix, it's a
pain.
This will devolve into an editor war, and I don't think it's a real
issue.
I'm not positive that it will. I can provide the magic incantations that
work for
On Wed, May 30, 2001 at 03:51:11PM +0200, H.Merijn Brand wrote:
On Tue 29 May 2001 19:25, Dave Mitchell [EMAIL PROTECTED] wrote:
=head2 Portability
Related to extensibility is portability. Perl runs on many, many
platforms, and will no doubt be ported to ever more bizarre and obscure
On Wed, May 30, 2001 at 06:27:39PM -0500, Jarkko Hietaniemi wrote:
On Wed, May 30, 2001 at 03:51:11PM +0200, H.Merijn Brand wrote:
On Tue 29 May 2001 19:25, Dave Mitchell [EMAIL PROTECTED] wrote:
=head2 Portability
Related to extensibility is portability. Perl runs on many, many
24 matches
Mail list logo
