Inconsistent Parrot / IMCC behavior

[Gregor N. Purdy]

I saw the report that Jako wasn't working right with the latest
Parrot, so I went to investigate.

I was running the various languages/jako/examples and I ran
across this oddity (after doing a fresh 'make' of Parrot and
in the languages/jako directory):

[gregor@borg jako]$ ./jako examples/fact.jako
[gregor@borg jako]$ ../../parrot examples/fact.imc
[gregor@borg jako]$ ../../parrot examples/fact.pasm
Algorithm F1 (The factorial function)
Calculating fact(15) = ...
... = 2004189184
[gregor@borg jako]$ ../../parrot examples/fact.pbc
Algorithm F1 (The factorial function)
Calculating fact(15) = ...
... = 2004189184
[gregor@borg jako]$

I find it odd that turning Parrot loose on the .imc file has a
different outcome than turning it loose on the .pasm and .pbc
files generated therefrom. The makeology responsible for those
files prints output like this:

[gregor@borg jako]$ make clean
rm -f examples/*.imc examples/*.pasm examples/*.list examples/*.pbc
[gregor@borg jako]$ make examples/fact.pbc
/usr/bin/perl -I lib jakoc examples/fact.jako > examples/fact.imc || (rm
-f examples/fact.imc && false)
../../parrot -o examples/fact.pasm examples/fact.imc || (rm -f
examples/fact.pasm && false)
../../parrot -a --output-pbc -o examples/fact.pbc examples/fact.pasm
[gregor@borg jako]$

Any thoughts on whether or not this would be my fault somehow?

Regards,

-- Gregor

--
Gregor Purdy gre...@focusresearch.com
Focus Research, Inc. http://www.focusresearch.com/

[Leopold Toetsch]

Gregor N. Purdy <gre...@focusresearch.com> wrote:

> I was running the various languages/jako/examples and I ran
> across this oddity (after doing a fresh 'make' of Parrot and
> in the languages/jako directory):

> [gregor@borg jako]$ ./jako examples/fact.jako
> [gregor@borg jako]$ ../../parrot examples/fact.imc

This segfaults because of illegal code. The "branch __IN_LINE_1" doesn't
get a proper fixup - branches are not supposed to go into different
compilation units.

Changing the code to:

.sub __INLINE_0
.globalconst int N = 15
bsr __INLINE_1
ret
.end

fixes this.

When compiling the PASM, all is one compilation unit and the error
vanishes.

leo

[Gregor N. Purdy]

Leo --

Thanks for the pointer.

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'

since I'd think that the later cases would be mirroring what is going
on inside parrot in the earlier ones. Where am I going wrong?

Regards,

-- Gregor

[Melvin Smith]

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. Its become too
aggravating to maintain, at least for me. Leo is welcome to
maintain v1 all he wants ;)

The rewrite of IMCC and will handle _one single flavor_ of language.
All syntax rules will apply the same, regardless of if it sees PASM ops
or PIR/IMC ops. There won't be a PIR -> PASM translation phase, either.
(I will probably relax the idea of compilation unit to allow simple streams
of bytecode, rather than require a wrapping sub).

Not that it helps you now, but I understand your frustration.

-Melvin

[Leopold Toetsch]

Melvin Smith <mrjol...@mindspring.com> 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.