Re: [cc65] Modules with self modifying code

Hi!

On Mon, Feb 07, 2011 at 09:26:51AM +0100, Gábor Lénárt wrote:
> Hi,
>
> On Sun, Feb 06, 2011 at 08:38:26PM +0100, Ullrich von Bassewitz wrote:
> >
> > Hi!
> >
> > On Sun, Feb 06, 2011 at 04:49:56PM +0100, Oliver Schmidt wrote:
> > > And placing the smc code in the data segment as I suggested wouldn't
> > > cause any surprise even for those:
> >
> > Ok, convinced. Let it be the data segment.
>
> As far as I see, these segment names and purposes are a bit confusing on
> 6502 any way, these were designed for platforms where there is more hw level
> protection of segments like:
>
> non-executable + read only = RODATA
> non-executable + read-write = DATA or BSS (the difference: BSS is not stored
>   but initialized to zero on run-time)
> executable + read only = CODE (or called TEXT originally??)
> executable + read-write = (would be) SMC??
>
> I always felt, that in most cases a 6502 target does not need to be
> separated (at least not with "default" targets, for sure, some targets like
> an OS - though I am not sure with lunix - may need these), the only thing is
> writeable or not, so in theory there is even not so much

Once in the early days of cc65, things were simple. There were CODE, DATA,
RODATA and BSS. And yes, ZEROPAGE, which is a special sort of BSS. I don't see
problems explaining these segments to anyone. These segments are not the cause
of the increased complexity.

Now look at all the other segments in use today: EXTZP, EXEHDR, LOADADDR,
LOWCODE, HIGHCODE, INIT, ZPSAVE, TRAILER, AUTOSTRT, MOVE, LC, ... It is far
more difficult to explain the reason of these segments to someone, but they
serve a purpose. They are here because there is a reason, and usually a
feature that would have to be dropped when removing the segment.

So what is this discussion about? Removal of RODATA? Do you really think this
would help?

> But if it's true, that we have not-so-much valid segment types (in the sense
> of 6502) then we could have even more one, the writable CODE segment, which
> would be the place for smc.

Nope. There is a reason why CODE and RODATA are readonly. See my story about
debugging the memory overwrite bug in elite in one of my last mails. Want to
know how I found the problem after *weeks* of frustration?

I restructured the sources, tried to make as much code as possible readonly
and place readonly code and data adjacent to avoid lots of small pieces with
different access modes. This was also the point when I started to remove the
self modifying code whereever possible.

Then I made a command file for VICE from the map file that marked all readonly
code as READONLY in VICE. The next time the memory overwrite occured, the VICE
monitor was triggered and two minutes later, the bug was fixed.

So while most of the 6502 machines do not have memory protection hardware, it
is available (Andre Fachat for example has developed a 6502 system with an MMU
and paging hardware), and where it is not available there's emulated hardware
with this feature.

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.