At 03:35 PM 5/29/2001 -0700, Larry Wall wrote:
>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.
Nope, the text editors aren't at all the issue. It's much more an issue o
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 04:25 PM 5/29/2001 -0400, Uri Guttman wrote:
>> here is an idea. if we use a pure stack design but you can access the
>> stack values with an index, then the index number can get large. so a
>> fixed register set would allow u
On Tue, May 29, 2001 at 04:36:51PM -0600, Nathan Torkington wrote:
> Dan Sugalski writes:
> > Okay--Parrot Object Code. (If I was feeling cleverer at the moment, I'd
> > come up with a name that has a snappier acronym. Alas I'm not... :)
>
> p-code. The p stands for Parrot :-)
No, it stands fo
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 02:15 PM 5/29/2001 -0700, Hong Zhang wrote:
>> > we have a simple set of load literal, push/pop (multiple) registers op
>> > codes.
>>
>> There should be no push/pop opcodes. They are simply register moves.
DS> The one ha
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.
Larry
Dan Sugalski writes:
> Okay--Parrot Object Code. (If I was feeling cleverer at the moment, I'd
> come up with a name that has a snappier acronym. Alas I'm not... :)
p-code. The p stands for Parrot :-)
Nat
At 03:26 PM 5/29/2001 -0700, Larry Wall wrote:
>Dan Sugalski writes:
>: Nah, bytecode'll have an endianness marker at the top. If you load in
>: bytecode with the wrong endianness, the loader will have to swap for you.
>
>Er. If they're not bytes, we can't call it bytecode.
Okay--Parrot Object C
Dan Sugalski writes:
: Nah, bytecode'll have an endianness marker at the top. If you load in
: bytecode with the wrong endianness, the loader will have to swap for you.
Er. If they're not bytes, we can't call it bytecode.
Larry
At 04:25 PM 5/29/2001 -0400, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> If someone can make a compelling argument for details on how the
> DS> registers should be done that should be visible to the bytecode
> DS> (Like, say, a variant on SPARC's windo
At 02:15 PM 5/29/2001 -0700, Hong Zhang wrote:
> > we have a simple set of load literal, push/pop (multiple) registers op
> > codes.
>
>There should be no push/pop opcodes. They are simply register moves.
The one handy thing about push and pop is you don't need to go tracking the
stack manually-
At 05:32 PM 5/29/2001 -0400, Bryan C. Warnock wrote:
>On Tuesday 29 May 2001 05:15 pm, Hong Zhang wrote:
> > > either each op code knows how many args it has,
> >
> > I like to do so, otherwise we will lose most of the performance gain.
>
>I would think, though, that some ops would benefit more fr
On Tuesday 29 May 2001 05:15 pm, Hong Zhang wrote:
> > either each op code knows how many args it has,
>
> I like to do so, otherwise we will lose most of the performance gain.
I would think, though, that some ops would benefit more from varargs.
String assembly comes to mind.
>
> > or we have
> here is an idea. if we use a pure stack design but you can access the
> stack values with an index, then the index number can get large. so a
> fixed register set would allow us to limit the index to 8 bits. so the
> byte code could look something like this:
>
> 16 bit op (plenty o
At 09:55 PM 5/29/2001 +0100, Graham Barr wrote:
>On Tue, May 29, 2001 at 04:48:59PM -0400, Dan Sugalski wrote:
> > 1) The indentation should be all tabs or all spaces. No mix, it's a pain.
> > (As has been already pointed out) 4 column indent per level, all spaces.
>
>Can you explain why you think
On Tue, May 29, 2001 at 04:48:59PM -0400, Dan Sugalski wrote:
> 1) The indentation should be all tabs or all spaces. No mix, it's a pain.
> (As has been already pointed out) 4 column indent per level, all spaces.
Can you explain why you think it is a pain. I would say converting between
all tabs
At 06:25 PM 5/29/2001 +0100, Dave Mitchell wrote:
>Well, My first draft of "Conventions and Guidelines for Perl Source Code"
>passed by with remarkably little scathing. Either you all loved it,
>or just didn't read it. (Shades of Warnock's Dilemma).
Consider it more a recognition of sensible thi
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> If someone can make a compelling argument for details on how the
DS> registers should be done that should be visible to the bytecode
DS> (Like, say, a variant on SPARC's windowing system, or forcing them
DS> on the stack such that
On 2001-05-29 18:25:45, [EMAIL PROTECTED] wrote:
>
> The following I apply:
>
> =over 4
>
> =item *
>
> 8-wide tabs
>
> =item *
>
> 4-wide indents for code, 2-wide indents for nested CPP #directives
Please don't *require* the use of literal TABs (8 characters wide) to
achieve 4-character in
I've been out of touch this weekend (and currently sorta swamped now) so
I've not been commenting, but here's a quick sum-up of what I've been
thinking about:
1) The paired register thing's silly. Forget I mentioned it.
2) The interpreter will have some int, float, and string registers. Some
Well, My first draft of "Conventions and Guidelines for Perl Source Code"
passed by with remarkably little scathing. Either you all loved it,
or just didn't read it. (Shades of Warnock's Dilemma). I've just produced
a second draft, hopefully taking on board the comments from the first round.
(And
On Sun, May 27, 2001 at 02:24:13PM -0600, Nathan Torkington wrote:
> I'd like to see activity on the topics behind:
> * perl6-stdlib
> * perl6-build
> Dan, Graham--should these lists persist in their current form?
Well I thonk that there should eventually be a perl6-stdlib, but
I think more nee
On Tue, May 29, 2001 at 12:38:27PM -0400, Dan Sugalski wrote:
> At 02:24 PM 5/27/2001 -0600, Nathan Torkington wrote:
> >Bryan C. Warnock writes:
> >I'd like to see activity on the topics behind:
> > * perl6-stdlib
> > * perl6-build
> >Dan, Graham--should these lists persist in their current for
At 02:24 PM 5/27/2001 -0600, Nathan Torkington wrote:
>Bryan C. Warnock writes:
>I'd like to see activity on the topics behind:
> * perl6-stdlib
> * perl6-build
>Dan, Graham--should these lists persist in their current form?
Got me, as I'm not on either set.
>It looks like the perl6-internals-
Simon Cozens <[EMAIL PROTECTED]> writes:
> On Tue, May 29, 2001 at 04:29:18AM -0700, A. C. Yardley wrote:
> > NOTE: "CLI Partition III - CIL (word, pdf)," a link to which is on
> > the bottom of the webpage, includes a description of their so-called
> > "Common Intermediate Language (CIL)."
>
>
On Tue, May 29, 2001 at 04:29:18AM -0700, A. C. Yardley wrote:
> NOTE: "CLI Partition III - CIL (word, pdf)," a link to which is on
> the bottom of the webpage, includes a description of their so-called
> "Common Intermediate Language (CIL)."
Just to keep people keeping things in perspective, the
To add insult to injury (or maybe not, depending on your pov),
here's a bit more, but this one's from Microsoft's site:
See http://msdn.microsoft.com/net/ecma/
NOTE: "CLI Partition III - CIL (word, pdf)," a link to which is on
the bottom of the webpage, includes a description of their so-called
26 matches
Mail list logo
