Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 8:30 AM +0200 4/20/04, Leopold Toetsch wrote: >> >>Why I second table? This just adds duplicate code paths and complexity. >>One constant table ought to be enough.
> Mainly because I was assuming that we were going to separate the > float, pmc, and string constants into separate tables for > locality-of-reference reasons and ease of doing reflective access. The constants are currrently a typed union, so there is some wasted space. OTOH constants compiled at the same time tend to stick together (modulo constant folding of course). Three distinct tables could have worse locality then one. Dunno. >>The freeze/thaw internals can change. We only have to invalidate >>existing PBCs, if the frozen image format differs. > Yep. I thought there was still some outstanding stuff, but it might > just be dodgy memory on my part. $ parrot parrot-config.imc VERSION 0.1.0 is accessing the frozen image of the config hash. Most of the basic types are working. >> > As for the actual declaration of the constants... That's going to be >>> somewhat interesting. I can see one of two ways of doing it: >> >>> 1) we execute the initialization code at compiletime and freeze the result >>> 2) We compile the initialization code and execute it at runtime to >>> create the PMC >> >>It probably depends on the PMC. *If* there are any side effects, >>initialization has to be done at run time. > Yeah, but we have to pick one. :( For .const PerlInt i = 5 or some such, the compiler knows the type and can freeze the compiled result. It's of course the question, what is all allowed to create a PMC constant. leo
