From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2005-03-31 10:41:41
Good morning!
On Thu, Mar 31, 2005 at 12:13:02AM +0200, fachat wrote:
> I have now added a new "chain" bit in the header mode word, to
> signal that the o65 is followed by another o65 file, e.g. for
> another memory segment.
It would be good to specify that it depends on the implementation if this bit
is honoured or not.
> I would like to specify two more header mode bits as "CPU" bits:
Which bits are these? It seems that the web document is unchanged.
> if 6502 mode:
>
> 00= 6502 original 6502 core [illegal opcodes]
> 01= 65C02 CMOS 6502 /w some bugfix, no illegal opcodes
> 10= 65SC02 65C02 enhanched, with Z register (always zero!), some new opcodes
> 11= 65CE02 some 16bit ops/branches, Z register is modofiable
>
> but if accepted here, this would be the final change to the
> v1.x set of releasesi (for now?).
There are quite some bits left in the mode word. If this is the final 1.x
version, why not spend a few more bits for more CPUs? This would help Gabor
and not harm anyone else. Just a suggestion:-)
> - o65 is currently not suitable as object format for
> cc65 - I don't know the reason, but maybe this could be
> fixed as well.
I doubt that, because it would require adding more features than there are
currently in o65:-) Here is an incomplete list, of what would be necessary:
* An almost unlimited number of segments.
* Per segment attributes: Name, readonly, bss & zeropage attributes, address
size, alignment, ...
* Support for full expression trees instead of simple relocations. The ca65
assembler can store *any* expression, with any number of external or
internal references in the object file for evaluation by the linker. It's
the job of the linker to check for arising problems, like circular
references.
* Support for "asserts": These are checks defined by the assembler and done
by the linker. For example, the check for
jmp ($xxFF)
is not hardcoded somewhere, but an assert. An assert has a condition
(which is an arbitrary expression) and an action. This feature is
available to the user, so someone who doesn't want symbol "foo" to be
relocated to address $1234 could write:
.assert foo <> $1234, error, "Arghh! Illegal value for foo!"
This assert is then stored in the object file, and read and checked by
the linker.
* String pools to save memory and to ease string compares: Strings are not
saved as is, but are indices into a pool of strings. The string pool
merges duplicate strings, so two identical identifiers have identical
indices in the string pool. For most things, integer compares can be used
instead of string compares.
* Special symbols: The cc65 object code format supports the notation of
module constructors and destructors. There's a generalized symbol type
for this.
* Source code info: The object file contains a list of all files that were
used to create the object file in question, and all expressions and code
fragments reference the source file. This means that the linker can output
error messages telling the source file and line of the code that had
problems. If a symbol is unresolved, the linker can and will tell you the
exact file(s) and line(s) where the symbol is referenced. There are also
time stamps of all sources stored in the object file, so at least in
theory, the linker could check if two files have been translated using the
same include file but with different time stamps (for practical reasons,
this check is not done).
* Debug info (incomplete): The object files contain information about all
symbols (not just exported ones), symbol type, and source code info on
assembler and even on C language level. Using this information, the linker
is able to generate line infos, telling which C line generated which
binary code in the resulting executable. This is thought to support a
debugger one day.
And maybe some more ...
> Did I miss anything? However, I am still wondering, what
> happens to a format with a almost non-existent toolchain:
? I think I don't get this question.
> and which systems will support it:
>
> - GeckOS
> - opencbm
Contiki (uses o65 for "programs" on 6502 platforms), maybe Lunix once it wakes
up from its hiatus:-)
BTW: Which executable format is Wings using? Since they're using xa, chances
are they're also using o65 in it's 65816 incarnation.
> I wonder, if I define a new - incompatible - format, how many
> people will actually use it?
Only speaking for me: As long as the current advantages of o65 are kept, and
the new format has useful new features, I would support it. I have to admit
that there are not many things that I could imagine to be useful but no
additional overhead. More CPU types are an example, maybe more segments - but
the latter case is almost crossing the border to "loose advantages of the
current format" (depends on the actual implementation).
Regards
Uz
--
Ullrich von Bassewitz uz@musoftware.de
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.