IMCC, classes & metadata

It appears IMCC's way of emitting instructions as it collects compilation
was a mistake (mine) and isn't going to work for metadata that needs to
be initialized first.

Basically all metadata has to be collected before any code can be emitted.
I was thinking of generating an _init routine that creates the classes,
so we have several possibilities.

Short term: Require all class definitions and other metadata to be
declared first in the PIR stream. Upon first non-metadata object (sub,
pccsub)
we flush the _init sub.

Long term: We should parse the whole PIR file before doing any sort of
code emission. This means collecting all the compilation units, running
the allocator and optimizer on each and then emit all metadata first
before emitting the rest of the units. This allows metadata to be throughout
the PIR stream.

This isn't really so big a deal since high level languages should be able to
emit PIR code with all metadata first anyway.

Comments?

-Melvin

Why? A class definition should AFAIK end up in the constant table as a
class PMC specifying the inheritance and attributes. So a .class
directive is from parsing POV a constant definition, like a string
constant.

That's true. pbc.c already has most of the necessary structures. These
should of course be rearanged, kept inside IMCC_INFO() and so on. But
basically it shouldn't be too hard.

We have to rearange all imcc globals anyway - there can't be globals or
multi-threading will break horribly.

That's not necessary AFAIK.

> -Melvin

leo

Requiring the metadata be in the stream before the code that uses it
doesn't seem particularly onerous, so I'm OK with it. (I would, I think,
like to avoid a multi-pass assembler... :)

Dan

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

True, but something has to change. Either the loader has to know how
to load a class (long term solution) or I have to write an _init routine.

I was aiming for a short term kludge to get classes working. Freeze/thaw
can break my kludge whenever it is done. (Unless you have a secret
patch ready)

Well, Bison C++ parsers are reentrant by default *pokes Dan*.... :)

-Melvin

> I was aiming for a short term kludge to get classes working. Freeze/thaw

Have a look, what I did with constant Subs. They are "serialized" as
plain text and unpacked from that. I real short term hack, but working
and doing, what's intendend to be done :)

Its not a problem of the parser alone (which in the meantime BTW has an
interpreter argument), all the other globals like the SymReg hash.
Please imagin whats goin' on, when two threads start compiling PIR code.

> -Melvin

leo