Melvin Smith <[EMAIL PROTECTED]> wrote: > At 08:01 PM 2/28/2004 -0800, Gregor N. Purdy wrote: >>I made the change, and now I get consistent results. I'll check that in. >> >>I am still not clear, though, on why we wouldn't have the same failure >>in all cases. I'd think these should be equivalent: >> >> * Running parrot on 'foo.imc' >> * Running parrot on 'foo.pasm' generated from 'foo.imc' >> * Running parrot on 'foo.pbc' generated from 'foo.pasm'
> You would think it would be straightforward. Its not, due to the > way we (Leo and I) mixed up IMCC and how it handles things, > especially the lexer. The problem is definitely a bug, and I think > we've made an error in trying to mix too many features and > lexing/parsing modes into the same compiler. Well, sometimes ago compiling PIR to PASM didn't even produce valid source code, mainly due to internal label naming. Anyway compiling to PASM isn't really ment to be equivalent to running code direclty (or producing a PBC). It's mainly for debugging purposes only. These steps are fine: - foo.imc -> run - foo.imc -> foo.pbc -> run - foo.pasm -> run - foo.pasm -> foo.pbc -> run But not (in all cases): - foo.imc -> foo.pasm -> anything You can call this a bug of course, but it was never[1] intended to work that way in all cases. There is really *no need* to compile to PASM and run that code. This is an outdated POV from times where assenble.pl was the one and only assembler. > ... Its become too > aggravating to maintain, at least for me. Leo is welcome to > maintain v1 all he wants ;) Me thinks that we should rework the whole structure of Parrot WRT compilers. Something like this: - a compiler/assembler is a loadable lib, which during load registers the filetype it can compile - a macro preprocessor is a loadable IO filter layer Now: - Parrot starts in src/parrot.c (finally :) - It does commandline handling and remembers all options - Parrot now loads default compilers which register their file type(s) - Parrot handles source file and commandline arguments over to a matching compiler > The rewrite of IMCC and will handle _one single flavor_ of language. Yep. I'm all for separating PASM and PIR lexing and parsing. The underlaying code generation could be based on an AST node scheme, similar to that used in YAL - Melvin, if you didn't look at YAL, please do). > -Melvin leo [1] except in the very beginning of course, when we had PIR->PASM->assemble.pl.
