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.