From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2005-03-30 20:57:15
On Wed, Mar 30, 2005 at 04:59:38PM +0200, Gabor Lenart wrote:
> On Wed, Mar 30, 2005 at 01:54:14PM +0200, Ullrich von Bassewitz wrote:
> >
> > Yeah, but if I can't ignore these optional features, I have a problem. If the
> > exact CPU type is encoded in an optional header field, I have to add code to
> > check for the flag that says "optional header present", then check for this
> > optional header, and within this header, check for the correct CPU. Currently,
> > the whole header is checked with a simple memory block compare. Even the
>
> Yes, memory block compare is used by me as well at the moment :)
>
> > (additional) check for the operating system is unnecessarily complex in my
> > eyes, because it's burried in other data records that may encode author,
> > time/date of compile and so on.
> >
> > I admit that the additional code will be just 50 bytes or so, but even
> > this is a lot on 6502 platforms. I'm scanning through the existing library
> > code in regular intervals to find a way to squeeze three or five bytes out
> > of heavily used routines, because I know that *every* program will benefit
> > from it with just a recompile (this is the nice thing about a library). If
> > would prefer to avoid adding 50 bytes for a CPU check, if I can.
>
> OK, then check out my idea about 'profiles' in my other mails I've sent
> today _AND_ at the end of this mail.
>
> >
> > > I know, I've written some code for C64 with ca65, I've asked something about
> > > the linker from you exactly on this topic, if you remember :)
> >
> > Yes, I remember:-) I've added the Intel/Zilog number format (100h) to ca65
> > after the mail exchange.
> >
> > > About the complexity: you're right, that's why I always try to find
> > > way to do it as an OPTIONAL stuff. I mean, you don't want to integrate
> > > support for this feature for YOUR loader.
> >
> > Unfortunately, I cannot ignore the CPU type. Trying to load code written for
> > the Z80 won't execute correctly (at best:-) on a 6502.
>
> I don't think so you should check because you should not even try to load
> another systems's objects :).
But to know this, I will have to check the CPU.
> Do you check for ALL type of problems? I mean if I try to crash your loader
> with doing format violations or others are you sure that ALL problems is
> detected by the loader and refuse to load (or refuse to continue to load)?
I'm not sure if the loader will detect all problems, but it will detect quite
some.
> If no, this is exactly the same situation: you
> should not try to load o65's created not for your software :)
No, there's a difference: Every check made means a crash less. You are right,
there are some things that cannot be checked, and there are others, that are
too costly. But that's not the situation we have: Currently I *do* check the
CPU, because it's part of the header. If someone creates 65816 modules, this
would be detected. This scenario is not as unlikely as it seems, and changing
the format, so that checks done now become too costly in the future is the
wrong way, I think. Especially since there is an easy way out: Just make the
format incompatible (no problem with this), and reserve a full byte in the
header for the CPU type. This would increase the code size by exactly one
byte, and would allow CPU checks to work.
> If you've read my format profile idea: let's define some unused bits
> of the mode word as 'profile indentifier'.
[...]
Yes, of course that could be done, and it would work. But is it really a good
idea to transfer o65 into a "one fits all" spec that allows to use it as a
base for any CPU starting from 8 bits to 128 bit supercomputers? Please note
that I'm not really opposed to your "profiles" idea. It would work, and I
would just use profile #0 for cc65. But features are not why I had choosen o65
in the first place - and most current uses of o65 were a result of my choice.
I'm pretty sure that I would not have considered o65 with all the additional
bells and whistles for use with loadable modules.
I see your point regarding additional CPU specs. But this could be done
without changing the idea behind o65 (or at least what I thought was the idea
behind it).
But after all, it's André who has to find his decision. I could easily live
with the proposed "profiles" solution. I just wouldn't use most of it.
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.