Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!mintaka!bloom-beacon!eru!hagbard!sunic!dkuug!freja.diku.dk!bombadil From: bombadil@diku.dk (Kristian Nielsen) Newsgroups: comp.sys.amiga.tech Subject: Re: Assembler Programming - Costs versus Benefits Message-ID: <1990Nov30.144853.2562@diku.dk> Date: 30 Nov 90 14:48:53 GMT References: <1990Nov25.040121.10773@zorch.SF-Bay.ORG> <1990Nov25.233007.19698@cs.umu.se> <7139@sugar.hackercorp.com> <1990Nov27.004859.16630@cs.umu.se> <7150@sugar.hackercorp.com> <7160@sugar.hackercorp.com> Organization: Department Of Computer Science, University Of Copenhagen Lines: 61 peter@sugar.hackercorp.com (Peter da Silva) writes: >In article 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. `-_-' >. 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!