Re: [cc65] Re: some patches

Hi!

On Wed, Mar 17, 2010 at 11:03:45PM +0100, Oliver Schmidt wrote:
> Maybe the semantics of --start-group / --end-group could be modified
> in a way that a library mentioned inside a group _before_ a second
> library is searched _before_ that second library for symbols
> referenced in that second library. This would allow to override
> symbols from the C library.

A better solution would be to have the linker being able to translate symbols.
I've had this idea a few years ago and it can be used to do all sorts of nifty
things. Simple example:

        _write  := _ide64_write
        _read   := _ide64_read

This would cause the linker to resolve the symbols _read and _write by
_ide64_read and _ide64_write respectively.

A more complex example would be

        * := [ $1_65816, $1_65C02, $1 ]

which would cause the linker to resolve each symbol "foo" by "foo_65816" if
this exists, by "foo_65C02" if that can be found, and by "foo" otherwise.

Having such an additional translation level would allow for all sorts of
things: Have 65C02 or 65816 versions of the library functions available, or
versions using self modifying code, use debug versions of some functions by
just relinking, or do simple replacements to support different hardware on low
level.

The drawback is, that as with all good ideas, it needs someone to implement
it. And as usual I have more good ideas than time to make them real :-)

> I'm no CBM insider but I seem to understand that there are quite some
> diverse solutions regarding disk I/O. From that perspective disk I/O
> clearly is a usecase for loadable drivers - at least on the CBMs. The
> only special thing is that there needs to be a default driver to
> actually load the loadable driver. But as far as I understand the
> Kernal allows for such a default driver to be very simple and very
> small. BTW: Contiki 1.x implemented this way a "fastloader" loadable
> driver loaded by the Kernal. And for PCs it's totally normal to use
> the INT13 BIOS calls to load disk drivers.

I've also thought about this solution but dismissed it. A program would need
the standard read routines anyway, plus o65 support (0.5 KB) plus malloc/free
(0.75 KB), plus the interface for the loadable driver, plus the loadable
driver itself which is slightly larger than the same code linked to the
application. So the overhead is several KB. And even programs that just need
read() will also get write(), because it's in the driver.

The overhead is not as large for programs that do already use loadable drivers
(like Contiki), but there are definitely others, which would be much larger
than before.

> Maybe a true case of german over-engineering, but maybe the solution
> to the seemingly broad range of disk I/O approaches on the CBMs.

For disk I/O, I think loadable drivers are really overkill. The difference to
the other loadable drivers is that disk I/O works without an additional
driver. The ide64 routines posted here are not necessary to make read/write
work. They are just making it faster. Which is nothing to sniff at, but it's
definitely different to mouse or joystick drivers. Without the latter the
hardware is completely unusable. And, having several KB of additional code (in
ALL programs) just to make reads and writes for ide64 faster is not a good
idea.

I do really think that having separate read and write functions is the way to
go. The only question is, how (and by whom) they're maintained, and how using
them is made as easy as possible.

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz@musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.