[perl #22352] PackFile imcc bug

I've been trying to run pbc2c.pl, and it's been dying. I traced the
problem down to Parrot::Packfile thinking that the size of the
bytecode segment is zero. However, it works fine when I use
assemble.pl to compile; the problem only arises when I compile with
imcc.

Luke

Our current problem is, that we have two assemblers and two PBC formats.
Keeping all in sync till now ends obviously at test level.

But we have finally to give up assemble.pl: its slow and it doesn't
conform to packfile/packout.c. As previous discussions did show, we will
need constant/debug/fixup/... segments per bytecode file. packfile.c has
with the directory approach all the infrastructure. assemble.pl probably
doesn't keep up with that.

I'm only waiting for tinderboxen showing imcc build and test results.
Before ok from these, we can't change things that need assemble.pl.

Anyway WRT pbc2c.pl: It does unroll a whole PASM file in one big C switch
statement, which is suboptimal for RL programs. So it seems - backed by
Daniels news today - this will not survive.

> Luke

leo

The perl assembler was never intended to be the permanent solution.
Rather, in typical Perl fashion, to get something working quickly until
such time as it's replaced by something else. If there's something
else, then ditch the perl assembler. Or at least reliance on it.
(Someone will undoubtedly replace it with a Perl-based PBC thingy
anyway, but as an add-on it can get out of sync.)

As far as the multiple PBC formats, I'd say ditch the old one there,
too. We never promised - and it fact warned - that file formats have
been subject to change. Most everything Parrot runs was just assembled
anyway, so it will continue to apply to the latest format. On the off
chance that someone really is using Parrot in some sort of production
mode and schlepping around old PBC files, a standalone format converter
would be a nice add-on. Perhaps even based on the add-on Perl-based PBC
thingy above.

It's way to early to get wrapped up in Parrot's own legacy.

--
Bryan C. Warnock
bwarnock@(gtemail.net|raba.com)

We need one more thing. The standard makefile needs to automatically
build imcc. Honestly I'd prefer just a single executable, named
parrot, that can handle assembly files, rather than the two
executables we're building now. If we can do that, we can ditch
assemble.pl.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

I would totally dig that. I use imcc for everything; why not just
call it "parrot" :-)

Luke

[Dan]>> ... Honestly I'd prefer just a single executable, named
[Dan]>> parrot

Why don't we just build a single executable, where the main c-source
isn't called test_main.c but parrot.c and the executable is parrot$EXE,
so what ;-)

I said, I'd prefer some additional tinderboxen results first, but as
imcc runs all tests on Win32 too, we could jump into the cold water
(which doesn't seem to be really deep anymore) instantly and just update
Makefile and the test scripts. Its all in place.

Just replace the env that runs now:
$ IMCC=imcc perl t/harness t/o*/ma*.t
with parrot.

[Dan]>> Dan
> Luke
leo, tried to reconstruct quotes for clarity.

I'm all for that as well. It would imply some code reorganization
(placing them in the same directory might make sense, or at least taking
imcc out of languages/ and putting it under the top level). Who should do
this? I'd be willing to help if given direction.

Also be aware that imcc currently isn't as portable as parrot is. It does
not build under lcc, for instance. I'll see if I can correct that, though.

--Josh

> I'm all for that as well. It would imply some code reorganization

Yep. Imcc should definitely move out off languages into its own subdir
under the top level (Not in the top level itself).

> ... Who should do

Moving directories around in CVS is AFAIK a PITA. The last such
operation was done in the repository directly, IIRC.

Wow, that fast. Thanks for the fixes.

> --Josh

leo

Yes, that's certainly the way to go for the actual dir structure change.
But first all the other little code changes that this would require need
to be figured out..

I started looking at what makefile changes would be needed.. i think the
first thing that really needs to be decided is whether we intend to use
recursive makefiles or not. Right now, parrot is half and half, and that
just isn't going to fly, long term.

The problem is, if you're really going to do recursive makefiles without
headaches, each makefile needs to be building a fairly self-sufficient
module. And at the moment, if we were to build a libimcc or something
like that and link it into parrot, it would in turn require libparrot to
build. This creates a bit of a chicken/egg problem.. Not
insurmountable, but certainly ugly. It would be somewhat less so if the
library bits were in a separate directory from the programs, so that imcc
and parrot would be able to pull in libparrot and libimcc without disaster.

However, that said, I am not a tremendous fan of recursive makefiles (or
of make in general, honestly).

I would suggest that we may want to move towards either a non-recursive
makefile system (see 'recursive make considered harmful',
http://aegis.sourceforge.net/auug97.pdf.. i have doubts about how well
this can work on a large scale project without something like gnu make
though), or something else altogether (cons, for instance).

Wow, That was a run-on sentence.

I know there was some coding done a while back towards rolling our own
make replacement, but I don't know what state it's in.. and rolling our
own will slow things down a bit- best to spend our resources on writing
parrot, not make, imho.. but i'm willing to go with whatever folks want
to do.

I'm willing to help out here- i can probably figure out how to link imcc
into parrot, but I think we need to resolve these directory structure /
build system issues first.

Does anyone own this problem?

--Josh

> The problem is, if you're really going to do recursive makefiles without

In the first place, I would just build it as now:
1) make static (= libparrot)
2) make imcc (= imcc/*.o + libparrot)
3) (re)name the executable from 2) parrot

We will need something like libimcc finally, but this is basically the
built executable w/o imcc's main.c.

leo

This is correct. But, we (read as "the keepers of the repository") are
happy to do this once in a while.

-R