From: Gabor Lenart (lgb_at_lgb.hu)
Date: 2005-03-29 13:37:30
On Tue, Mar 29, 2005 at 10:26:41AM +0200, fachat wrote:
> > Nice. However I've got an idea.
> >
> > The method .o65 format encodes the CPU "platform" the object code /
> > executable was created for is very limited. I mean, the .o65 format _is_
>
> This is indeed a good point. I see a number of options of which I am not
> clear of and which should probably be discussed here:
First of all, I think we should thinking about the point of purpose of
marking (system/CPU/"OS") architecture. I mean, you may create an OS (using
eg .o65 for native object/executable format). If your program (o65
executable) uses major amount of a given computer, eg VIC-II, SID, 6510,
CIA, etc of the Commodore 64, you can say that binary is for C64. However,
your program may only interact with the kernel / system library / whatever
ONLY, so if you provide a standard API towards programs, the same binary may
run on different computers using compatibe CPUs as well. So in this case,
the exact computer is not important but only the CPU itself. However it's
even possible, to create eg object file which contain only constants,
initalized data eg, or maybe abstract executable (like java bytecode let's
say just simplier stuffs: however this is treated as data from the strict
point view of the CPU even if you can treat as an exacutable: for real it's
interpreted), in this case even the CPU is not important if the system
software presents which can use THIS type of object files.
So there're huge amount of points you can view this whole issue ...
You can create header options for mainly humans. I mean: if I got an .o65
file, I can check several info on this object, however a typical sw
component using this object eg to load it will not check ALL the options etc,
or at least using a byte string to compare the part of the header against
to check this file is acceptable or not.
So we can say that specifying target CPU / OS / system the object/binary
was created for is usefull to create some dependencies eg "this requires
65816 CPU", "this is for Lunix" and so on.
Maybe you can even say that it's overcomplicated theory to try to solve
the "meaning of life"-like problems in an object format created mainly
for 8 bit systems :)
> * "compatible options"
> (i.e. old 6502 files still work, and new 6502 files work on old machines)
>
> 1) re-define an existing mode bit to define an "extended" header, that
> allows for two new header bytes (length to be discussed), e.g.
> with one byte CPU family ($65 = 65xx, $80 = Z80, $68 = 6809 etc)
> and one byte CPU model (e.g. 6502 vs. 65C02)
> The mode bits in question to be redefined would be 65816 or the "size" bit.
> (is the format used for 65816 or 32bit code anyway?)
>
> 2) another version would be to declare the 65816 bit deprecated
> and require a new CPU-type optional header as already defined.
> Which would be different from the OS type, as there are systems with
> multiple types of CPU in one system.
I think this is the best solution. However I always treated file format
versions as "non compatible" eg, if you presents a v1.3 o65 object for
a tool created for v1.2 formats, it may not interpret v1.3 even if it hasn't
got incompatible changes but you DID NOT know this when you wrote that tool
at the time of v1.2 format ... If it's true it's even not important to
keep accurate compatibility, because old tools will refuse work with newer
formats. Or the other case: I'm wrong here and you always take care of
keeping backward compatibility. In this case sorry for the false information,
at this moment I don't remember that there is full backward compatibility or
not ...
> Unfortunately this defines some "asymmetry" between the 6502 and
> other CPUs. However, I see no compatible way to change that
No asymmetry, because there was not "OFFICIAL support" for eg Z80, so you
can say, that eg Z80 support is introduced in v1.3 (or 1.4? ;-) when
"65816 flag" is obsolated as well and should be not depend on by tools
written for >v1.2 formats.
- Gábor
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.