From: Gabor Lenart (lgb_at_lgb.hu)
Date: 2005-03-30 21:41:22
On Wed, Mar 30, 2005 at 08:57:15PM +0200, Ullrich von Bassewitz wrote:
> > > 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.
No :) Read new mode bit below please.
> > 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.
Fine, I did not check this, sorry!
> 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
No, as I've said I would introduce a new mode bit to mean "old CPU type bit
(6502/65816) is obsoleted you should ignore it and check with the new
method instead". If this bit IS set, you can stop now and refuse further
work with that object. However you're right it's a "bit" messy solution.
> 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.
Yes. But there're more features, like multiple segments which creates some
problems cannot be solved easily with a little modificaton only like
inserting a new byte into the header to solve CPU type specification
easily. My attempt to solve the CPU type problem with optional header and
such was inspirated by the 'compatibility' issue. However you're right about
the overcomplicated situation
>
> > 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
No of course not :) I don't want to convert my Linux install to use .o65
instead of ELF ;-) Seriously, we're talinkg about 8 bit CPUs not 128
bit supercomputers :) And this is an area where amount of developers and users
are not comparable eg developers and users of "modern" PCs for example.
So in this case it's even more important to create some "standard", even
if the standard consist of multiple "profiles" but at least there is someone
WRITTEN which can be implemented if someone wants it.
> 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. And you're right, if you don't need it, do not use it :)
But somebody may need it.
> 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).
Yes. This was the first thought. But eg multiple segments would be nice at
least for me. Of course you don't have to use it with cc65, I haven't said
that.
> 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.
Yes. I have only one problem. If I _NEED_ multiple segment support while
o65 does not present and André decides not to support it, of course I can
modify the format for myself. Or I can use another format. Or I can create
a completly new format. However someone may need this feature too and will
do this too. So we have got two formats which are for the same but they're
incompatible. o65 is also chance to create some kind of 'standard' in wider
range when speaking about 8bit systems. And if you don't want to use
other profiles you won't feel pain - so no problem - but it is a solution
for other people like me. Also this is good for creating some kind of
semi-standard, and also each profile would be o65 in somewhere so you don't
need to start from zero at least if you want to use other profile, or multiple
profiles or whatever, since there are common roots.
So I see it's absolutly better to create a bit complicated scheme (like my
idea, of course better solution can be found, probably) than to have
several absolutly different home grown (I mean every developer would have
totally different) formats.
Anyway please warn me to stop flaming if you find my mails meaningless or
desctructive :) or something. I don't have such a plans I only want to
show the importance about creating a GOOD standard for 8bit developments.
If André thinks that we can brake the format (incompatibility) at ANY level,
care should be taken to brake it in a way which is useful for multiple purposes.
- Gábor
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.