From: Gabor Lenart (lgb_at_lgb.hu)
Date: 2005-03-30 11:16:03
On Wed, Mar 30, 2005 at 10:38:41AM +0200, Ullrich von Bassewitz wrote: > > On Wed, Mar 30, 2005 at 09:59:48AM +0200, Gabor Lenart wrote: > > BTW, another comment. As far as I know, .o65 format allows one text segment, > > right? I would like to use multiple text segment in the future, like > > initalization code should be dropped after executing at startup. Somewhere > > it is useful. > [...] > > Am I crazy, or it is a useful idea? :) > > I have to admit that I don't like the idea. As I said before, the beauty of > the o65 format is its simplicity. For me, it is definitively a disadvantage if > Andre would start to pack all sorts of additional features and optional > headers into the format. The cc65 module loader is less than a half KB in > size, and in my eyes, the goal should be to minimize this even further. But > every feature extension needs more code and will therefore increase the size > of the loader. No, no, you don't need to increase the loader complexity since we're talking about OPTIONAL features. Of course the VERY main goal should be always the simpliest format you can create for a given task. This is extermly important because we're about computers without GiGs of memory and GHz's of CPU clock ... So of course you're right! Any major addition to the format should be considered as optional feature which should be easily ignored for a software using the format but don't want to use some kind of features of the in-theory allowed set. > This does not mean that the idea of multiple segments itself is bad. cc65 > supports many segments and is doing exactly what you describe above (an INIT > segment that may be dropped after startup). But o65 is not the place to do it I know, I've written some code for C64 with ca65, I've asked something about the linker from you exactly on this topic, if you remember :) About the complexity: you're right, that's why I always try to find way to do it as an OPTIONAL stuff. I mean, you don't want to integrate support for this feature for YOUR loader. But it would be nice if the format itself would be able to support advanced features like this, even if it is not implemented by most linkers, loaders etc. Only the ability to do this. Why? Because otherwise someone may invent different formats for different tasks so there will be dozens of formats. Brrr. And it is very nice for o65 format to become something 'de facto' standard for 8 bit computing when speaking about object / executable format. But this is not possible if you must drop the idea of using .o65 if you want any not-trivial features like multiple segments. However I absolutly agree that simplicity is a major advantage of this format. But why don't want to support advanced features as well when they're OPTIONAL, so you don't want to implement in your loader at all! But allows for others to use this format with features like multiple segments. > - IMHO. > > If a more capable format is really needed, my suggestion would be to > create a different format spec, instead of packing all this into o65. But > beware: Such a more capable format would have competition. Currently o65 > is the king of its niche, because it is simple, well defined and allows > the smallest possible loaders on a 6502 machine. With more features, Agreed. So I don't see the problem: make new features as optional, you don't need to implement. It's ONLY about 'standard' I mean if it is announced as format description it creates somekind of 'standard' if at least two people try to use: they have compatibility then without thinking on a new format. Maybe any other people just don't implement these optional stuffs and no pain at all. > there's also more choice, because there are other, established object code > formats. Well what about 16bit ELF format? :-) -- - Gábor Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.