On Oct-23, Leopold Toetsch wrote: > Steve Fink wrote: > > >I suppose I ought to try to wrap up a release one of these days. > > > > - Artificial goal: I want the list of pending patches to be smaller > > than one screenfull before I release. Fortunately, I have a large > > screen. > > I did set 2 of them to "Applied". I'll wade through my contributions and > set status accordingly.
Thanks. > >* Keyed access > > - Either way, the current keyed support isn't complete. > > Adding a couple of lines to assemble.pl, which do the same as my patch > WRT imcc would make these multi_keyed operations available to HL. Then > we could look at usage patterns and finally decide, what to do. > (Who could extend the assembler?) Sounds good to me. But it does suggest a question -- are there any compelling reasons to preserve the separate assembler? Given that imcc appears to be a strict superset of the assembler these days, I'm tempted to standardize on imcc. Anyone want to argue otherwise? Architecturally, I suppose it would be nice to have a separate library for only processing PASM code, but I don't see that as hugely important. And perhaps the correct method of obtaining that would be by carving out a pasm component of imcc and having the main imcc delegate unrecognized lines to it. But the assembler seems to be a somewhat religious issue, so I'll not jump to conclusions. > >* Bytecode format > > > - I still don't understand why we can't write our own > > serializers/deserializers for ELF or some other standard format, > > I don't see the point, why to use ELF. The new proposed packfile format > should give us all we need. It's my knee-jerk "standards are good" reaction. While the proposed format provides everything we're thinking of at the moment, it seems like there are a lot of other things we might want to be able do with packfiles in the future. Our problem set feels pretty similar to the ELF problem set. The major counterargument I can envision is that it's too complicated and provides way more functionality than we need -- but although I really don't know that much about it, I'm under the impression that ELF is a pretty simple format. It mostly just sounds scary because it happens to be used for complex purposes. To my naive thinking, using a standard could provide some useful advantages. Mostly, I like the general idea of using a standard because a bunch of other presumably intelligent and motivated people have already dealt with all the niggling little issues of naming, referencing, total and partial symbol table stripping, etc. that we may not have thought of yet. ELF, and other formats like it, provides support for an arbitrary number of sections, a place to put indexes, segments, section attributes, etc. Going further out on a limb, it might even be possible to use ELF for some of the things it is normally used for, rather than just a hollow packaging that we stuff our own things into. gdb could make some sense of it automatically. We could store read-only bytecode wads in shared memory. PBC files could be executed as native binaries on ELF-based systems. We could use existing ELF tools to, at the very least, provide test result verification. ELF is certainly not the only possibility. In the past we've mentioned COFF and IFF. Java's .class file format comes to mind too. Even PNG could serve as a general-purpose container. They all pretty much boil down to a variant of a magic-number, some amount of versioning information, maybe an endianness specifier, and an index pointing to the offsets and sizes of a bunch of named sections. On the other hand, talk is cheap and I personally don't plan on trying to implement any of this, so it doesn't really matter what I think. :-)
