At 9:13 AM +1000 10/26/02, Rhys Weatherley wrote:
Huh? No, you misunderstand. Each chunk of the bytecode has a separate TOC for stuff like this. The full identifier would be file/chunk/entry, which should be reasonably guaranteed to be unique. When the compiler's emitting code to reference a piece of binary data (which is essentially a big binary string constant, but I realize that having it in separate segments is terribly useful) it can turn any human-readable identifier into the internal identifier the engine needs to look up the actual data.Dan Sugalski wrote:># Instead, lets just give an entry number. We can have arbitrary data ># chunk #1, #2, #3, and so on. I'm not sure it'll buy us much having ># names attached. > >What happens if two tools (say, a custom debugger and the Perl compiler) >both use the same segment number for something? Names make collisions >less likely. Whoever's writing the bytecode file needs to deal with that--hopefully there's only one writer. I'm in the middle of getting the API down on electrons, so we should have something to savage reasonably soon.I don't think you can guarantee that. Sooner or later someone will download the packfile spec and write a stand-alone compiler that generates bytecode directly, using none of the Parrot tools. If such a compiler needs an extension section, what number do they give it? (I'll be using imcc for C#, but others might want to do things manually).
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
