At 09:42 AM 9/13/2001 -0400, Gregor N. Purdy wrote:
>Dan --
>
> > > * The recognition of register types means that you can't use labels
> > > like 'I4'. It would be nice if registers and labels were in
> > > different namespaces.
> >
> > I don't think this is necessary. Odds are almost nobody'll be writing
> > parrot assembler once we have a working parser/compiler combo to generate
> > the bytecode automatically, so I don't think it's worth the effort. Simple
> > is OK at this level. :)
>
>I was thinking along the lines of having a complete assembly language
>for writing programs for the Parrot ISA, with all that that implies.
>If I'm the only one thinking that way, that's ok, but it just seems to
>me to be the right thing: A powerful ISA + A powerful assembler +
>multiple powerful language compilers.
Fair enough.
Okay, never mind--go ahead and build a powerful macro assembler. Heck, I'll
use it even if nobody else does. :) I'm working on a PDD on the assembler
syntax, but if you're so inclined you're welcome to it.
>What, exactly, will be written directly in pasm? Low-level ops will be
>written in C, high-level stuff can be written in whatever language is
>built on top of PISA (Parrot Instruction Set Architecture). I was
>imagining a set of intermediate support stuff to be written in pasm.
Actually, I'm expecting almost nothing to be written in pasm after we get a
working parser and compiler. We might write template code for the compiler
in it, but that's probably about it. Well, other than the JAPHs that aren't
being written in APL or Intercal or something. (I can see someone writing a
befunge parser just for the wacky JAPHs possible...)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
