[perl #22352] PackFile imcc bug

0 views
Skip to first unread message

Luke Palmer

unread,
May 28, 2003, 5:13:57 PM5/28/03
to bugs-bi...@rt.perl.org
# New Ticket Created by Luke Palmer
# Please include the string: [perl #22352]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22352 >


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


Leopold Toetsch

unread,
May 28, 2003, 7:03:14 PM5/28/03
to perl6-i...@perl.org, perl6-i...@perl.org
Luke Palmer <bugs-...@netlabs.develooper.com> wrote:

> 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.

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

Bryan C. Warnock

unread,
May 28, 2003, 9:34:46 PM5/28/03
to perl6-i...@perl.org
On Wed, 2003-05-28 at 19:03, Leopold Toetsch wrote:
> Our current problem is, that we have two assemblers and two PBC formats.
> Keeping all in sync till now ends obviously at test level.

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)

Dan Sugalski

unread,
May 31, 2003, 2:26:26 PM5/31/03
to l...@toetsch.at, perl6-i...@perl.org, perl6-i...@perl.org
At 1:03 AM +0200 5/29/03, Leopold Toetsch wrote:
>Luke Palmer <bugs-...@netlabs.develooper.com> wrote:
>
>> 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.
>
>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.

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

Luke Palmer

unread,
May 31, 2003, 2:37:05 PM5/31/03
to d...@sidhe.org, l...@toetsch.at, perl6-i...@perl.org
> At 1:03 AM +0200 5/29/03, Leopold Toetsch wrote:
> >Luke Palmer <bugs-...@netlabs.develooper.com> wrote:
> >
> >> 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.
> >
> >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.
>
> 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.

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

Luke

Leopold Toetsch

unread,
May 31, 2003, 4:04:07 PM5/31/03
to Luke Palmer, d...@sidhe.org, perl6-i...@perl.org
Luke Palmer wrote:


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

> I would totally dig that. I use imcc for everything; why not just
> call it "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.

Josh Wilmes

unread,
May 31, 2003, 7:04:00 PM5/31/03
to Dan Sugalski, l...@toetsch.at, perl6-i...@perl.org

At 14:26 on 05/31/2003 EDT, Dan Sugalski <d...@sidhe.org> wrote:

> 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.

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


Leopold Toetsch

unread,
Jun 1, 2003, 5:40:05 AM6/1/03
to Josh Wilmes, Dan Sugalski, perl6-i...@perl.org
Josh Wilmes wrote:

> At 14:26 on 05/31/2003 EDT, Dan Sugalski <d...@sidhe.org> wrote:
>
>
>>Honestly I'd prefer just a single executable, named
>>parrot,

> 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).


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

> this? I'd be willing to help if given direction.


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


> 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.


Wow, that fast. Thanks for the fixes.


> --Josh

leo


Josh Wilmes

unread,
Jun 1, 2003, 8:24:47 PM6/1/03
to Leopold Toetsch, Dan Sugalski, perl6-i...@perl.org
At 11:40 on 06/01/2003 +0200, Leopold Toetsch <l...@toetsch.at> wrote:
> 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
> > this? I'd be willing to help if given direction.
>
>
> Moving directories around in CVS is AFAIK a PITA. The last such
> operation was done in the repository directly, IIRC.

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

Leopold Toetsch

unread,
Jun 2, 2003, 4:04:02 AM6/2/03
to Josh Wilmes, perl6-i...@perl.org
Josh Wilmes <jo...@hitchhiker.org> wrote:
> At 11:40 on 06/01/2003 +0200, Leopold Toetsch <l...@toetsch.at> wrote:
>> Yep. Imcc should definitely move out off languages into its own subdir
>> under the top level (Not in the top level itself).

> 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.

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

Robert Spier

unread,
Jun 1, 2003, 10:11:46 PM6/1/03
to perl6-i...@perl.org

> 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 this? I'd be willing to help if given direction.

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

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

-R


Reply all
Reply to author
Forward
0 new messages