🚀 go-pugleaf

peter@sugar.hackercorp.com (Peter da Silva) writes:

>In article <CEDMAN.90Nov28142350@lynx.ps.uci.edu> cedman@golem.ps.uci.edu (Carl Edman) writes:
>> A correct 68000 program runs unchanged on a 68030.
[. . .]
>Basically, writing a portable program is harder the lower the level you write
>the program at. If you do everything through intuition in C, you're unlikely
>to cause headaches for Amiga 3000 users. If you do everything in assembly, it's
>a lot harder to keep all the differences between the different processors
>straight... because they become exposed to the programmer.

>I'm not saying "it's impossible to write a portable 68000 program in assembly",
>but rather "it's a whole lot harder to write one". Quit with the theoretical
>BS and look at the real world.
>-- 
>Peter da Silva.   `-_-'
><peter@sugar.hackercorp.com>.

  How about discussing what these differences/incompabilities actually are? 
This way, programmers could see for themselves that is isn't that hard to
write compatible programs, or decide that it is not worth the bother
(having just purchased a GVP 28MHz 3001 board, I certainly think the former!)
Below is a list of problems known to me:

1. Most important: 68020/30 boards are faster!!! This should be a trivial
point, but do you know how many demos/games/other programs that break on an
accelerator board because of this? The problem is using busy-wait loops when
waiting for hardware-devices such as disk, audio etc. Just look at a recent
posting to this group about MFM-decoding and reading the disk directly
through the hardware. Lets hope that accelerator boards that makes the cpu
go 12 times faster also speeds up the disk by the same factor! Even if you
take over the machine completely, the amiga has several possibilities for
providing timer functions (in the CIA/B chips), that will at least work
until the hardware registers are changed, so please use them.

2. MOVE from SR traps in Usermode on 68010/20/30. It seems that this is not
much of a problem. But remember that exec.library has the function GetCcr
(or something similar) to get the condition codes in a compatible way. Also,
if the need is desperate, it should be possible to simulate the MOVE in
software (i think i've heard of such a thing somewhere).

3. MOVE.{wl} does NOT trap on bigger cpu's. Now if this breaks a program,
it would seem to me that the programmer is asking for trouble.

4. The exeption frame is different. This affects direct use of interrupts
and traps (not system-supported use.)

5. Self-modisfying code and code on the stack is incompatible with the
instruction-cache. (BTW, can somebody explain why code on the stack fails? I
actually did this once in a program that boots directly into a 256-line
CLI-window (on PAL machines), so shame on me!). If possible, this can be
cured by disabling the cache; however, I think a lot of people will agree
that this is not a real solution.

It wopuld be interresting (and usefull!) to hear if someone could comment on
the above, add what I have forgotten or don't know, and correct me where
(not if) I'm wrong. It would be of benefit to everyone if programs stopped
breaking just because the programmer lacked information about how to support
higher cpu's.


-- 
==========================================================================
Kristian Nielsen                          |      ///   Only the AMIGA
Student at DIKU, University of Copenhagen |     ///
(Department of Computer Science)          | \\\///     makes it possible!