xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (11/25/90)
Just an anecdote to add fuel to the fire. I used to work for the folks who owned the weather service, national geodetic survey, etc. The weather service, in particular, was in the habit of buying the fastest available computers, then programming huge weather model software suites all in assembler, "for speed". The only problem was, when, every few years, a much faster machine became available from a new vendor, the huge software suites had to be rewritten from the specifications. This process typically took five years from start to tuned, screaming fast code, and it really was the fastest code that would run on that machine, at least twice as fast as higher level language code out of the best then current optimizing compilers. The problem was, new machines running four to ten times as fast were coming along every two to three years, so that by the time the assembler code was running, it was running on obsolete hardware in terms of leading edge technology. _If_ the huge software suites were available to compile and run from higher level languages on the then current speed champion computers, the higher level code would run faster _in_ _the_ _same_ _year_ than the assembler, because the assembler had two or three more years of rewrite to complete. This is a general problem. Assembly may be fast, but an existing assembly suite cannot, generally, take advantage of the fastest current hardware, so _when_ _development_ _time_ _is_ _taken_ _into_ _account_, assembly runs _slower_, not faster, on any given date, given a wide open choice of computer platforms, for any non-trivial code suite. If you want your big piece of code to run the fastest it can run _today_ _on_ _any_ _platform_, you are always money ahead to program in a higher level language, so that you can port to the fastest platform while it still _is_ the fastest platform. Fast code that I can't use on my faster platform doesn't help me. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
dvljhg@cs.umu.se (J|rgen Holmberg) (11/26/90)
I agree that large projects generally should not be written in assembler. Projects running into 2 years or more are not the norm though. Most programs out there take less to write ( and infinity to maintain ) and there are times when assembler is necessary. Try and write a fast shoot'em up in C or higher level languages. You can write most of it in C, but not all. In such a case the obvious choice would be to write the main code in C, the editors and help- programs in C and optimize graphic display routines in assembler. This might even allow for multitasking shoot'em ups. I would love to do all coding with an icon-based program generator. But by the time I have a machine that will run such programs at a speed that allows me to do that I will want to write programs that it can't run fast enough. Using Amigavision I can write stuff that I dreamt of doing on my spectrum but, alas, I don't want to. Jorgen -- ******************************************************************************* email dvljhg@cs.umu.se - other ways to communicate are a waste of time. Everything I say is always true, just apply it to the right reality. "Credo, quia absurdum est."
peter@sugar.hackercorp.com (Peter da Silva) (11/26/90)
In article <1990Nov25.233007.19698@cs.umu.se> dvljhg@cs.umu.se (J|rgen Holmberg) writes: > Try and write a fast shoot'em up in C or higher level languages. I've done it. Tracers is 100% C. And it runs faster than I can keep up with. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
dvljhg@cs.umu.se (J|rgen Holmberg) (11/27/90)
In article <7139@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1990Nov25.233007.19698@cs.umu.se> dvljhg@cs.umu.se (J|rgen Holmberg) writes: >> Try and write a fast shoot'em up in C or higher level languages. > >I've done it. Tracers is 100% C. And it runs faster than I can keep up with. You can write a fairly complex, fast game in C. If you want to program something like the what psygnosis, bitmap brothers, random access, factor5 and others are putting out, with large bobs and lots of other stuff taking raster-time you will have to go assembly at least for part of the code. Jorgen -- ******************************************************************************* email dvljhg@cs.umu.se - other ways to communicate are a waste of time. Everything I say is always true, just apply it to the right reality. "Credo, quia absurdum est."
dolfing@cs.utwente.nl (Hans Dolfing) (11/28/90)
>In article <7139@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >>In article <1990Nov25.233007.19698@cs.umu.se> dvljhg@cs.umu.se (J|rgen Holmberg) writes: >>> Try and write a fast shoot'em up in C or higher level languages. >> >>I've done it. Tracers is 100% C. And it runs faster than I can keep up with. >You can write a fairly complex, fast game in C. If you want to program >something like the what psygnosis, bitmap brothers, random access, factor5 >and others are putting out, with large bobs and lots of other stuff taking >raster-time you will have to go assembly at least for part of the code. >Jorgen That's what this whole discussion is about. It seems better to write almost the whole program in C for - Readability - Maintainability - Portability - Less bugs (on the average) reasons. If it is unavoidable to use assembler for speed or other reasons, than write parts of your code in assembler. Otherwise, !please! don't. Nobody is interested in unreadable assembler programs that are 5% faster than a (hopefully better readable) C equivalent. -------------------- Hans Dolfing (dolfing@cs.utwente.nl) "The human mind is superior to machine logic because it can either use or reject the logic and its formal systems."
peter@sugar.hackercorp.com (Peter da Silva) (11/28/90)
In article <1990Nov27.004859.16630@cs.umu.se> dvljhg@cs.umu.se (J|rgen Holmberg) writes: > You can write a fairly complex, fast game in C. If you want to program > something like the what psygnosis, bitmap brothers, random access, factor5 > and others are putting out, with large bobs and lots of other stuff taking > raster-time you will have to go assembly at least for part of the code. Almost certainly true. On the other hand, very few of these games run on my Amiga 3000. If they were in C they would certainly be fast enough on this machine. (not to mention that Psygnosis and the Bitmap Brothers tend to specialise in absolutely glorious games that are extremely low in playability, but that's another point) -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
jnmoyne@lbl.gov (Jean-Noel MOYNE) (11/29/90)
In article <1990Nov28.105607.26577@cs.utwente.nl> dolfing@cs.utwente.nl (Hans Dolfing) writes: > reasons. If it is unavoidable to use assembler for speed or other reasons, than > write parts of your code in assembler. Otherwise, !please! don't. Nobody is > interested in unreadable assembler programs that are 5% faster than a > (hopefully better readable) C equivalent. Well, it really depends on the way you program in asm ! If your asm programs are only 5% faster than your C ones, then forget about asm. But if you need speed (the main reason you write part of your code in asm usually), and if you know about good asm programming then you can use asm and it will be more than 5% faster than C. And you can write very clear sources in asm. Presentation and comments will do it. I really believe that if you want to write a nice arcade game on the Amiga, then you have to use asm, at least for a part of your game (usually everything linked to the display). I would even say that if you want to use all the resources of the machine, then you have to bypass the OS and do some 'dirty' programming (by dirty, I mean accessing the hardware directly using _custombase). I would also say that you don't need to write all your code in asm. But you can write C/asm sources which are very readable, maintanable, and bug free (even if it's harder to debug asm). As for portability ... well I don't believe to much in portability for games (I'm speaking graphic intensive games). Since the Amiga is the best machine for these games, you should use the blitter and the copper as much as you can ... and if you're using them to the limit, your code won't be portable. If you want to see portable code, just take a look at all these games comming from the Atari ST, or the one made to be sold on the ST, the clones and the Amiga. They all look alike, and none of them takes advantage of the Amiga possibilities. Of course, I know that a lot of software companies want to be able to sell more games by having it ported to other machines ... JNM -- These are my own ideas (not LBL's) " Just make it!", BO in 'BO knows Unix'
cedman@golem.ps.uci.edu (Carl Edman) (11/29/90)
In article <7150@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: In article <1990Nov27.004859.16630@cs.umu.se> dvljhg@cs.umu.se (J|rgen Holmberg) writes: > You can write a fairly complex, fast game in C. If you want to program > something like the what psygnosis, bitmap brothers, random access, factor5 > and others are putting out, with large bobs and lots of other stuff taking > raster-time you will have to go assembly at least for part of the code. Almost certainly true. On the other hand, very few of these games run on my Amiga 3000. If they were in C they would certainly be fast enough on this machine. (not to mention that Psygnosis and the Bitmap Brothers tend to specialise in absolutely glorious games that are extremely low in playability, but that's another point) If only I knew why Peter insist on thinking that Assembler Programs are less portable (among 68000 upward) than C programs. He is not talking about sources, but about executables. To make one fact 100% clear (for those who didn't know it): The 680x0 is upward compatible. Apart from some quite uncommon (and pretty useless) instructions any legal 68000 code is also legal 68030 code. That is the whole point about having 680x0 in all the amigas. A correct 68000 program runs unchanged on a 68030. What Peter obviously means are dirty hacks. They don't work on all machines / OS combinations. But that is a totally different issue. Ugly hacks can be done in (almost) any language. I've explained that before to him, but obviously he didn't listen. Please stop making that silly claim. Carl Edman Theorectical Physicist,N.:A physicist whose | Send mail existence is postulated, to make the numbers | to balance but who is never actually observed | cedman@golem.ps.uci.edu in the laboratory. | edmanc@uciph0.ps.uci.edu
mwm@raven.relay.pa.dec.com (Mike (My Watch Has Windows) Meyer) (11/29/90)
In article <8289@dog.ee.lbl.gov> jnmoyne@lbl.gov (Jean-Noel MOYNE) writes:
Well, it really depends on the way you program in asm ! If your asm
programs are only 5% faster than your C ones, then forget about asm. But
if you need speed (the main reason you write part of your code in asm
usually), and if you know about good asm programming then you can use asm
and it will be more than 5% faster than C.
Yeah, if you're only getting 5% out of recoding in asm, you're
probably doing something wrong. In the right circumstances, you can
buy almost a factor of 10 more speed out of asm.
Of course, if you did it right in the first place, and went to a good
CS reference library instead of the asm manual, you'd realize that the
factor of 10 is the bare beginnings of what you can do. Instead of
talking about 10 times as fast, you talk about n-squared as fast. And
you can still code in something where you don't have to worry about
the trivia.
<mike
--peter@sugar.hackercorp.com (Peter da Silva) (11/29/90)
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. Ah, then explain why Atari ST programs don't run on a 68020. There are lots of instructions that work differently between the 68000 and 68030, and any program that uses them will behave differently on different machines. Oh, you can say "but those aren't correct 68000 programs", which is all well and good but in the real world these instructions exist and are percieved as being useful to the sorts of folks who write manic games in assembler. 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>.
cedman@golem.ps.uci.edu (Carl Edman) (11/30/90)
In article <7160@sugar.hackercorp.com> 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. Ah, then explain why Atari ST programs don't run on a 68020. There are lots of instructions that work differently between the 68000 and 68030, and any program that uses them will behave differently on different machines. Oh, you can say "but those aren't correct 68000 programs", which is all well and good but in the real world these instructions exist and are percieved as being useful to the sorts of folks who write manic games in assembler. I haven't heard about the ST in a long time, but last time I checked, the reason why current STs don't work with higher processors (in contrast to the amiga, which has run higher processors almost forever), is that the OS of the ST was written sloppily. OSes sometimes have to use dirty programming, and as long as they do it that is fine. Amiga OS has been written in a way which is compatible with higher processors, ST OS hasn't. User programs for the ST should run unmodified under higher processors. 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 really don't know about which "all the differences" you are talking about. I've programmed both and there really aren't any incompatibilities. I'm all for using Intuition and not writing to the screen memory directly. But you can do that just as well in assembler. And intuition.library does not screen you from any processor incompatibilities. 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. There are lots of 68030 instructions which don't run on a 68000. Almost all 68000 instructions run on a 68030. The only minor exceptions to this are quite obscure accesses which should only be made in supervisor mode (in which no user programm should run) anyway. If I may quote the "Processor book for the 680x0 family" with respect to the 68020 (the translation is mine): "The 68020 has been extended in many areas. Still it remains program - compatible with the other CPUs in the family. Certain limitations of compatibility affect routines which process exceptions. But on the User-level the 68020 is capable to run all programs written for 680x0 family without changes." Good enough ? Theorectical Physicist,N.:A physicist whose | Send mail existence is postulated, to make the numbers | to balance but who is never actually observed | cedman@golem.ps.uci.edu in the laboratory. | edmanc@uciph0.ps.uci.edu
kdarling@hobbes.ncsu.edu (Kevin Darling) (11/30/90)
>> A correct 68000 program runs unchanged on a 68030. - Carl > Ah, then explain why Atari ST programs don't run on a 68020. [...] > 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... [...] > 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 Depends on your "real" world ;-). In my [OS9] world, I haven't found a single 68000 program written in the last seven years that doesn't work on any 680x0. So it's obviously quite possible to write portable (within the same OS) asm programs. It can be, and _is_, done easily (the same goes for reentrancy). No, none of them were hot games; and yes, many game programmers are braindead when it comes to thinking about (any) compatability. Still, and especially when talking also about non-game applications, ST/Amiga/etc 68K asm programmers who write non-upward-compatible code have no more excuse than C programmers who might do the same. best - kevin <kdarling@catt.ncsu.edu>
dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer) (11/30/90)
In article <7160@sugar.hackercorp.com> 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. < <Ah, then explain why Atari ST programs don't run on a 68020. There are lots of <instructions that work differently between the 68000 and 68030, and any program <that uses them will behave differently on different machines. Could you please give details about the User instructions (i.e. instructions which can be made when running in User mode, not Supervisory mode) which behave differently on a 68000 and a 68020 [or 68030] ? I think only "move from SR" now traps but the OS should take care of this. <"but those aren't correct 68000 programs", which is all well and good but in <the real world these instructions exist and are percieved as being useful to <the sorts of folks who write manic games in assembler. Aha, one difference might be that these guys are writing self modifying code which may not work on a 680[234]0 as the changes go into the data cache not the main memory or instruction cache. -- _ _ / U | Dolf Grunbauer Tel: +31 55 433233 Internet dolf@idca.tds.philips.nl /__'< Philips Information Systems UUCP ...!mcsun!philapd!dolf 88 |_\ If you are granted one wish do you know what to wish for right now ?
peter@sugar.hackercorp.com (Peter da Silva) (11/30/90)
In article <CEDMAN.90Nov29102235@lynx.ps.uci.edu>, cedman@golem.ps.uci.edu (Carl Edman) writes: > Amiga OS has been written in a way which is compatible > with higher processors, ST OS hasn't. User programs for the ST should > run unmodified under higher processors. Um, no. It seems the ST operating system interface includes a bunch of calls made by using reserved opcodes. Which turned into real opcodes on the 68020. Big mistake. If it was just O/S internals stuff they could have fixed it by now. In any case, none of it was necessary. > And intuition.library does not screen you from any processor > incompatibilities. No, but high level languages do. Try doing "move SR,ea" in C some time. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
hclausen@adspdk.UUCP (Henrik Clausen) (11/30/90)
In article <CEDMAN.90Nov28142350@lynx.ps.uci.edu>, Carl Edman writes: > In article <7150@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > Almost certainly true. On the other hand, very few of these games run on my > Amiga 3000. If they were in C they would certainly be fast enough on this > machine. > > If only I knew why Peter insist on thinking that Assembler Programs > are less portable (among 68000 upward) than C programs. He is not > talking about sources, but about executables. Well, most programs are distributed as executables, I think :-) > To make one fact 100% clear (for those who didn't know it): > A correct 68000 program runs unchanged on a 68030. Assuming no SW timing loops etc., yes. > What Peter obviously means are dirty hacks. They don't work on all > machines / OS combinations. But that is a totally different issue. > Ugly hacks can be done in (almost) any language. An Asm programmer has to know about bits, registers, offsets etc. that a C programmer wouldn't bother about. Thus, "smart" tricks come much easier to the asm programmer than to the C ditto, and Asm programs break on my A3000. Actually, dirty tricks are quite complex and unreadable (but certainly doable) in C. In Asm, it's much more natural. If this isn't a problem with the language, it's with the programmers! Facts are, most programs that breaks on the 68030 are written in Asm. Every programmer that wants to play dirty on the system will pick Asm. > I've explained that before to him, but obviously he didn't listen. That's just in theory, and therefore does not apply to Asm (-: :-) -Henrik | Henrik Clausen, Graffiti Data | | ...{pyramid|rutgers}!cbmvax!cbmehq!adspdk!hclausen | \__"Deine Zauber binden wieder, Was die Mode strengt geteilt" - Shiller__/
bombadil@diku.dk (Kristian Nielsen) (11/30/90)
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!
mt87692@tut.fi (Mikko Tsokkinen) (12/01/90)
> Could you please give details about the User instructions (i.e. instructions > which can be made when running in User mode, not Supervisory mode) which > behave differently on a 68000 and a 68020 [or 68030] ? I think only > "move from SR" now traps but the OS should take care of this. > <"but those aren't correct 68000 programs", which is all well and good but in > <the real world these instructions exist and are percieved as being useful to > <the sorts of folks who write manic games in assembler. > Aha, one difference might be that these guys are writing self modifying code > which may not work on a 680[234]0 as the changes go into the data cache not the > main memory or instruction cache. 90% of all games I have ever seen for amiga doesn't run with faster processors because the disk loader and other waiting is badly written. They use wait loops like this: wait move.l #2000,d0 dbra.s d0,wait And this the absolutely same code as comes from c-compiler when you use similar wait tactics. It seems too hard for 90% of programmers (on any language) to use CIA timers. On the other hand the assembler programs are more likely to crash because most of c-programs are written using the OS and the waiting is done using the OS functions (this can done as easily with assembler). But it's very true that c-sources are much portable. The assambler is not ment to be portable because the nature of assembler (direct processor commands). Binaries in any language is just as unportable. MIT -- Bubble Bobble
peter@sugar.hackercorp.com (Peter da Silva) (12/01/90)
In article <536@ssp9.idca.tds.philips.nl>, dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer) writes: > Aha, one difference might be that these guys are writing self modifying code > which may not work on a 680[234]0 as the changes go into the data cache > not the main memory or instruction cache. That's a good one. Of course that's a very effective way of writing BitBlt on a 68020 if you explicitly flush the I-cache. Henry Spencer has claimed (and I believe him) that using this technique you can get 100% data bus utilisation with bitblt on a 68020. Of course on a 68000 you should probably just use the blitter. :-> Anyway, I've observed a positive correlation between "manic assembler program" and "does not work on the 68030". Assembly for critical code is one thing, but writing the whole thing in assembly is pure machismo. > 88 |_\ If you are granted one wish do you know what to wish for right now ? A time machine with extra plutonium in the trunk. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (12/01/90)
In article <1990Nov30.144853.2562@diku.dk>, bombadil@diku.dk (Kristian Nielsen) writes: > 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. I think you've done an admirable job of picking out the problems. About the only one I can think of is that memory above 16M isn't available to Zorro-II DMA, so you better make sure your disk buffers are allocated below that if you do direct disk I/O on a 2000 with a 68020 and over 16M RAM. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
cedman@golem.ps.uci.edu (Carl Edman) (12/01/90)
In article <7167@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: In article <CEDMAN.90Nov29102235@lynx.ps.uci.edu>, cedman@golem.ps.uci.edu (Carl Edman) writes: > Amiga OS has been written in a way which is compatible > with higher processors, ST OS hasn't. User programs for the ST should > run unmodified under higher processors. Um, no. It seems the ST operating system interface includes a bunch of calls made by using reserved opcodes. Which turned into real opcodes on the 68020. Big mistake. If it was just O/S internals stuff they could have fixed it by now. In any case, none of it was necessary. Ah, yes , I remember. The graphics calls , weren't it ? It has been a long time since I last read or thought about the ST. Anyway ,Amiga OS has avoided such obvious brain-damage. > And intuition.library does not screen you from any processor > incompatibilities. No, but high level languages do. Try doing "move SR,ea" in C some time. I've programmed a lot in both assembler and C, and I've never used this instruction. I don't know why any user program would want to use it. I don't know why the only program which I know of which used it , "Calc", did use it. I don't know why anybody complains about it as this incompatibility is quite trivially fixed (with any number of PD programs out there). It is unfortunate that this problem exists, but it really is only a very minor problem. Carl Edman Theorectical Physicist,N.:A physicist whose | Send mail existence is postulated, to make the numbers | to balance but who is never actually observed | cedman@golem.ps.uci.edu in the laboratory. | edmanc@uciph0.ps.uci.edu
farren@well.sf.ca.us (Mike Farren) (12/01/90)
peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1990Nov25.233007.19698@cs.umu.se> dvljhg@cs.umu.se (J|rgen Holmberg) writes: >> Try and write a fast shoot'em up in C or higher level languages. >I've done it. Tracers is 100% C. And it runs faster than I can keep up with. So have I. Well, CRYSTAL QUEST isn't exactly a shoot-em-up, exactly, but it can get damned fast! And all in C, except for five (count 'em, five) short assembler routines (about 10-20 lines each, one 100 lines or so) where I needed to do something special. Old C, at that - it was compiled under Lattice V3.something. -- Mike Farren farren@well.sf.ca.us
maniac@howlin.cs.unlv.edu (Eric J. Schwertfeger) (12/02/90)
> Ah, then explain why Atari ST programs don't run on a 68020.
Four reasons I've seen 68000 programs not run on higher processors.
The
ST may have one of these problems
1) Software timing loops run faster. On the Amiga, we have hardware
timers
to handle that. I don't know if the ST does
2) Since the 68000 only had 24-bit addressing, some 68000 OS's used
the
Upper 8 bits of the longword to store tag data. The Mac OS does
this,
but doesn't use the upper 8 bits to address memory, which is why
you
still can't get much memory into the older Mac II's. Minix does it
too (so I've been told).
3) The Exception frame is different for the different models of
680x0.
The Amiga OS handles the different frames. I'd assume the Mac
does
this. Which means that if you throw out the Amiga OS, you need to
write your own exeption handlers, and if you're lazy, you won't
bother writing code to handle the different frames. Again, I
don't know
if the ST OS handles the different frames at all.
4) The move.w SR,<ea> is the ONE instruction that changed from the
68000
to the higher family members. I've never seen a legitimate use
for
this instruction outside of the OS, and even if you do need it,
there's
a functionally identical OS call you can use. Unless of course,
you're throwing out the OS. I don't know if the ST OS uses that
instruction.
Eric J. Schwertfeger, maniac@jimi.cs.unlv.eduhclausen@adspdk.UUCP (Henrik Clausen) (12/02/90)
In article <7160@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. > > Ah, then explain why Atari ST programs don't run on a 68020. I can tell you that. Atari used the FPU instructions in TOS, which is obviously illegal. So no TOS ran on 68020's for years, and noone bothered to write programs that where 68020 compatible. Hard times ahead for the TT. So, it's a lot easier to do it right on the Amiga, as the OS actually allows us to use these nice fast CPU's. > There are lots of instructions that work differently between the 68000 and > 68030, and any program that uses them will behave differently on different > machines. Actually, it's not _that_ many. But just one of these killer instructions, and you're dead meat. > Peter da Silva. `-_-' > <peter@sugar.hackercorp.com>. -Henrik | Henrik Clausen, Graffiti Data | | ...{pyramid|rutgers}!cbmvax!cbmehq!adspdk!hclausen | \__"Deine Zauber binden wieder, Was die Mode strengt geteilt" - Shiller__/
dcl@ncsc1.ATT.COM (Dave Love) (12/06/90)
mt87692@tut.fi (Mikko Tsokkinen) writes: > 90% of all games I have ever seen for amiga doesn't run with faster >processors because the disk loader and other waiting is badly written. >They use wait loops like this: >wait move.l #2000,d0 > dbra.s d0,wait That's probably the only loop guaranteed to take the same amount of time on ANY processor. Forever... :) -- Dave Love dcl@ncsc1.att.com CIS: 75126,2223 bix: dlove <insert standard disclaimer here>
eachus@linus.mitre.org (Robert I. Eachus) (12/06/90)
In article <7173@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: In article <1990Nov30.144853.2562@diku.dk> bombadil@diku.dk(Kristian Nielsen) writes: >> It would 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. >I think you've done an admirable job of picking out the problems. >About the only one I can think of is that memory above 16M isn't >available to Zorro-II DMA, so you better make sure your disk >buffers are allocated below that if you do direct disk I/O on a >2000 with a 68020 and over 16M RAM. And the difference which kills AmigaBASIC: The 68000 ignores the upper 8 bits of addresses, but they are valid on the 68020/68030. Using the upper bits of a pointer as flag bits is a VERY bad thing, but some people never learn. It would have been nice if the 68000 checked these bits and trapped, but it doesn't. -- Robert I. Eachus with STANDARD_DISCLAIMER; use STANDARD_DISCLAIMER; function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...
jnmoyne@lbl.gov (Jean-Noel MOYNE) (12/07/90)
In article <EACHUS.90Dec5182932@aries.linus.mitre.org> eachus@linus.mitre.org (Robert I. Eachus) writes: > And the difference which kills AmigaBASIC: The 68000 ignores the > upper 8 bits of addresses, but they are valid on the 68020/68030. > Using the upper bits of a pointer as flag bits is a VERY bad thing, > but some people never learn. It would have been nice if the 68000 > checked these bits and trapped, but it doesn't. Sure, guess where AmigaBasic comes from .... From a machine where every body uses theses bits as flags ... and from a machine who has now to ask you "the application is not 32 bits clean, do you want to launch it anyway ?" (this requester is here for 99% of the progs) when you try to use something under A/UX. (-: How do you believe we had AmigaBasic that fast on the Amiga ? They didn't write it from scratch. JNM -- These are my own ideas (not LBL's) " Just make it!", BO in 'BO knows Unix'
stoller@cbmcel.UUCP (Martin S. Stoller) (12/07/90)
In article <184a3cc5.ARN04295@adspdk.UUCP> hclausen@adspdk.UUCP writes: >In article <CEDMAN.90Nov28142350@lynx.ps.uci.edu>, Carl Edman writes: > >> In article <7150@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >> Almost certainly true. On the other hand, very few of these games run on my >> Amiga 3000. If they were in C they would certainly be fast enough on this >> machine. > An Asm programmer has to know about bits, registers, offsets etc. that a >C programmer wouldn't bother about. Thus, "smart" tricks come much easier >to the asm programmer than to the C ditto, and Asm programs break on my >A3000. Actually, dirty tricks are quite complex and unreadable (but >certainly doable) in C. In Asm, it's much more natural. > >| Henrik Clausen, Graffiti Data | >| ...{pyramid|rutgers}!cbmvax!cbmehq!adspdk!hclausen | >\__"Deine Zauber binden wieder, Was die Mode strengt geteilt" - Shiller__/ If a C programmer knows nothing about bits, registers, offsets, vectors, etc... THEN SHE/HE IS NOT A C PROGRAMMER!!! There are many simple and easy ways in C to play with bits, like >> and << and ~ and & and | and stuff like that. There are even two structured things, namely enum and the 16 bit struct (struct Foo={unsigned magic:2;misc:4;jello:5;...};). As fr Offsets... How do you think I can programm a library, with proper function calls, which will make sence to the system??? And I very well know what a REGISTER is; after all, it IS a C keyword :^). My two cents worth... -- Regards, UUCP: [{(uunet|pyramid|rutgers)!cbmvax}!cbmehq!cbmcel!stoller
csg019@cck.cov.ac.uk (-~=Zaphod=~-) (12/07/90)
In article <MT87692.90Nov30211512@uikku.tut.fi> mt87692@tut.fi (Mikko Tsokkinen) writes: > > 90% of all games I have ever seen for amiga doesn't run with faster >processors because the disk loader and other waiting is badly written. >They use wait loops like this: > >wait move.l #2000,d0 > dbra.s d0,wait > >And this the absolutely same code as comes from c-compiler when you use similar >wait tactics. It seems too hard for 90% of programmers (on any language) to >use CIA timers. On the other hand the assembler programs are more likely to >crash because most of c-programs are written using the OS and the waiting is >done using the OS functions (this can done as easily with assembler). Good point, but using different wait techniques won't help with disk speed, this is becuase as far as i know (correct me if i'm wrong!) the disk DMA speed is still the same, so you will still have to wait the same time for the disk block to load on all config's. -- *********/// O O **A member of S.H.I.T. (Super High Intelegence Team)**///*** * /// u Fight, defeat and kill organized laming. /// * * \\\ /// --- Zaphod of Intuition csg019@uk.ac.cov.cck ok? \\\ /// * ****\\X//**********************************************************\\X//******
caw@miroc.Chi.IL.US (Christopher A. Wichura) (12/09/90)
In article <1990Dec7.103652.17887@cck.cov.ac.uk> csg019@cck.cov.ac.uk (-~=Zaphod=~-) writes: >In article <MT87692.90Nov30211512@uikku.tut.fi> mt87692@tut.fi (Mikko Tsokkinen) writes: >> >> 90% of all games I have ever seen for amiga doesn't run with faster >>processors because the disk loader and other waiting is badly written. >>They use wait loops like this: >> >>wait move.l #2000,d0 >> dbra.s d0,wait >> >>And this the absolutely same code as comes from c-compiler when you use similar >>wait tactics. It seems too hard for 90% of programmers (on any language) to >>use CIA timers. On the other hand the assembler programs are more likely to >>crash because most of c-programs are written using the OS and the waiting is >>done using the OS functions (this can done as easily with assembler). > >Good point, but using different wait techniques won't help with disk speed, >this is becuase as far as i know (correct me if i'm wrong!) the disk DMA >speed is still the same, so you will still have to wait the same time for >the disk block to load on all config's. Yes, but that's the problem. The disk controller isn't running that wait loop. The CPU is. And on a faster machine it is going to finish that loop all that much faster. Thus, the company's mumbo-jumbo piece of crud loader thinks the drive has finished loading whatever it needed and goes on to the next step when, in fact, the drive has not finished. -=> CAW /////////////////////////////////////|\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ Christopher A. Wichura |Real programmers don't play tennis, or caw@miroc.chi.il.us (my amiga) |any other sport that requires you to u12401@uicvm.uic.edu (school account)|change clothes. Mountain climbing is |OK, and real programmers wear their Please! Do not send mail to my school|climbing boots to work in case a account unless mail to miroc bounces.|mountain should suddenly spring up in I often do not check uicvm.uic.edu |the middle of the machine room. for periods in excess of a week. | --Unix Fortune \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\|//////////////////////////////////////
hclausen@adspdk.UUCP (Henrik Clausen) (12/10/90)
In article <194@cbmcel.UUCP>, Martin S. Stoller writes: > In article <184a3cc5.ARN04295@adspdk.UUCP> hclausen@adspdk.UUCP writes: > >In article <CEDMAN.90Nov28142350@lynx.ps.uci.edu>, Carl Edman writes: > > > > An Asm programmer has to know about bits, registers, offsets etc. that a > >C programmer wouldn't bother about. > > If a C programmer knows nothing about bits, registers, offsets, vectors, > etc... THEN SHE/HE IS NOT A C PROGRAMMER!!! There are many simple > and easy ways in C to play with bits, like >> and << and ~ and & and | > and stuff like that. Now, that's quite a different matter. I do know all about binary aritmetics, bitfields etc., and how to use this for speed. What I don't know, and don't want to know, are the exact locations and functions of Agnus, Denise & Paula registers, CPU status registers etc., nor do I take much interest in the particular CPU I'm running on, as long as it doesn't force me to do nasty things, like the older Intel CPU's did. > How do you think I can programm a library, with proper > function calls, which will make sence to the system??? And I very well > know what a REGISTER is; after all, it IS a C keyword :^). I stated above that the Asm programmer needs to know LOTS more details than the C programmer does, and that's the fact. -Henrik ______________________________________________________________________________ | Henrik Clausen, Graffiti Data | If the Doors of Perception where cleansed, | | ...{pyramid|rutgers}!cbmvax! | Man would see Reality as it is - Infinite. | \______cbmehq!adspdk!hclausen___|_________________________________W. Blake___/
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (12/12/90)
In <18574883.ARN11d9@adspdk.UUCP>, hclausen@adspdk.UUCP (Henrik Clausen) writes: >In article <194@cbmcel.UUCP>, Martin S. Stoller writes: > >> In article <184a3cc5.ARN04295@adspdk.UUCP> hclausen@adspdk.UUCP writes: >> >In article <CEDMAN.90Nov28142350@lynx.ps.uci.edu>, Carl Edman writes: >> > >> > An Asm programmer has to know about bits, registers, offsets etc. that a >> >C programmer wouldn't bother about. >> >> If a C programmer knows nothing about bits, registers, offsets, vectors, >> etc... THEN SHE/HE IS NOT A C PROGRAMMER!!! There are many simple >> and easy ways in C to play with bits, like >> and << and ~ and & and | >> and stuff like that. > > Now, that's quite a different matter. I do know all about binary >aritmetics, bitfields etc., and how to use this for speed. > > What I don't know, and don't want to know, are the exact locations and >functions of Agnus, Denise & Paula registers, CPU status registers etc., >nor do I take much interest in the particular CPU I'm running on, as long >as it doesn't force me to do nasty things, like the older Intel CPU's did. > >> How do you think I can programm a library, with proper >> function calls, which will make sence to the system??? And I very well >> know what a REGISTER is; after all, it IS a C keyword :^). > > I stated above that the Asm programmer needs to know LOTS more details >than the C programmer does, and that's the fact. You seem to be implying that the assembler programmer needs to know the details of things like the exact locations of Agnus, Denise, and Paula registers. If this is indeed your contention, you are flat wrong. -larry -- The only things to survive a nuclear war will be cockroaches and IBM PCs. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+