From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2005-04-01 10:44:21
On Fri, Apr 01, 2005 at 01:19:06AM +0200, fachat wrote:
> fixed. Please look over the CPU codes again,
> 65C02 was already there, only named "CMOS 6502", I renamed it too.
Looks ok now.
Another idea just for discussion (sorry for coming up with it so late): Would
it be useful to reserve another header bit as a flag that the bss segment
should be zeroed out (instead of leaving it uninitialized)?
This is just an idea, and I'm not sure if it is useful, so let me explain: The
C standard guarantees that anything not intialized explicitly in the source
has the '0' value of the data type. This must not necessarily correspond to a
binary zero, but on most platforms - including 6502 ones - it does. This means
that the bss segment, which contains these uninitialized values can be simply
overwritten by zeroes on program startup.
cc65 driver modules are written in assembler. And, they can be linked to the
executable, instead of loading them at runtime. Those two things mean, that a
driver cannot or need not rely on a zeroed bss segment. Since the cc65 loader
was also thought to load code written in C, it does always clear bss. Not
filling the bss segment would save time when loading, and would saves code, if
the flag is required by a loader. If the module is loaded from a floppy disc,
the time overhead is probably not noticeable, but if the module is loaded from
extended memory (REU, GeoRAM or similar), it is.
Please don't take this idea as a request. I'm not sure myself, how useful it
is. If the flag is in the header, it would require more code to check the
header. Requiring this bit to be set in the header for the cc65 module loader
is possible. This would leave the header check as is, but save the code and
time overhead of the bss fill. It would also make the loader dangerous when
loading code written in C, because uninitialized data will now contain random
values. So maybe others can comment on it. And, if you don't want to make any
more changes to the final draft, it's ok with me. Too late is too late:-)
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.