From: Gabor Lenart (lgb_at_lgb.hu)
Date: 2005-03-30 16:59:38
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 :). 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)? If no, this is exactly the same situation: you
should not try to load o65's created not for your software :)
If you've read my format profile idea: let's define some unused bits
of the mode word as 'profile indentifier'. Let's say we have use 4 bits for
this, this is 16 profiles. If 'base profile' is profile #0, you can continue
to do only a memory block compare, since if profile bits in mode fields is
not zero the CPU specification is present, but in this way you won't
get this problem at all, because the memory block compare will fail at
the mode word and you don't need to continue to work with this object at all :)
Of course in this way you say that you don't want to use advanced CPU
specification at all since it is not in the base o65 profile, but if you
don't need that, don't use :)
I think creating several completly different object formats if worse than
creating ONE specification with profiles with slightly different features,
but at least there is SOME common part and 'de facto standard' behind this
as this way, even these formats are not fully compatible of course ...
- Gábor
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.