Re: New draft version of o65 file format

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.