ken@hpclkms.HP.COM (Ken Sumrall) (02/24/90)
I just got the 68040 User's Manual, and was perusing the appendix which discusses the various features of the different members of the 68000 family. In the table on page A-3, the CALLM instruction is shown to be implemented only on the 68020. However, on page 1-1, the 68040 is claimed to be user object code compatible with previous members of the 68000 family. What gives? Does the phrase "user object code compatible" mean "mostly user object code compatible"? Ken Sumrall ken%hpda@hplabs.hp.com ...!hplabs!hpda!ken
valentin@cbmvax.commodore.com (Valentin Pepelea) (02/25/90)
In article <300003@hpclkms.HP.COM> ken@hpclkms.HP.COM (Ken Sumrall) writes: >I just got the 68040 User's Manual, and was perusing the appendix which >discusses the various features of the different members of the 68000 family. >In the table on page A-3, the CALLM instruction is shown to be implemented >only on the 68020. However, on page 1-1, the 68040 is claimed to be >user object code compatible with previous members of the 68000 family. To my understanding, the CALLM and RTM instructions were really meant to be operating system intructions only. Can you see any uses for these instructions in an application program? I don't. >What gives? Does the phrase "user object code compatible" mean "mostly >user object code compatible"? If you want to express dissatisfaction with user object code compatibility, I suggest you mention the missing floating point instructions in the 68040. Motorola has the FPSWP (Floating Point Sowftware Package) which is supposed to terminate the unimplemented floating-point instructions in software. When I called them to find out what we have to do to get it, I was told $xxxx please. Not that it's much, it isn't. But since we'd have to provide something like that in the operating system we release with an 040, it makes the claim "fully user object code compatible" rather, ahem, incomplete. I know, I know, the response to that is going to be "we didn't mean to include the coprocessor". *sigh* Valentin -- The Goddess of democracy? "The tyrants Name: Valentin Pepelea may distroy a statue, but they cannot Phone: (215) 431-9327 kill a god." UseNet: cbmvax!valentin@uunet.uu.net - Ancient Chinese Proverb Claimer: I not Commodore spokesman be
wayne@dsndata.uucp (Wayne Schlitt) (02/26/90)
In article <300003@hpclkms.HP.COM> ken@hpclkms.HP.COM (Ken Sumrall) writes: > > [ ... ] > In the table on page A-3, the CALLM instruction is shown to be implemented > only on the 68020. However, on page 1-1, the 68040 is claimed to be > user object code compatible with previous members of the 68000 family. > it is my understanding that motorola went out and looked and found _no_one_ who was actually using the CALLM and RTM instructions. i am sure that there are people who did use them, but none of the major compilers or operating systems do. i dont think this is going to be a major problem. first, the 68000 and the 68020 were not 100% user object code compatible either. (the MOVE SR instruction became privileged...) secondly, the '030 doesnt have the CALLM instruction either so this is really old news. -wayne
seanf@sco.COM (Sean Fagan) (02/26/90)
In article <300003@hpclkms.HP.COM> ken@hpclkms.HP.COM (Ken Sumrall) writes: >In the table on page A-3, the CALLM instruction is shown to be implemented >only on the 68020. However, on page 1-1, the 68040 is claimed to be >user object code compatible with previous members of the 68000 family. Only one member of the 68k family implements the CALLM (and RETM) instructions: the 68020. Nobody used it, apparantly, so it was dropped by the time the '30 came out. -- Sean Eric Fagan | "Time has little to do with infinity and jelly donuts." seanf@sco.COM | -- Thomas Magnum (Tom Selleck), _Magnum, P.I._ (408) 458-1422 | Any opinions expressed are my own, not my employers'.
dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer) (02/26/90)
In article <300003@hpclkms.HP.COM> ken@hpclkms.HP.COM (Ken Sumrall) writes: >I just got the 68040 User's Manual, and was perusing the appendix which >discusses the various features of the different members of the 68000 family. >In the table on page A-3, the CALLM instruction is shown to be implemented >only on the 68020. However, on page 1-1, the 68040 is claimed to be >user object code compatible with previous members of the 68000 family. In my MC68030 User's Manual (section 12.1.3, page 12-3): When used in a system originally designed for an MC68020 a difference a programmer must be aware of is that the MC68030 does not support the CALLM and RTM instruction of the MC68020. If code is executed on the MC68030 using either the CALLM or RTM instructions, an unimplemented instruction exception is taken. So the MC68040 is apparently more compatible with an MC68030 than with an MC68020. -- Dolf Grunbauer Tel: +31 55 433233 Internet dolf@idca.tds.philips.nl Philips Telecommunication and Data Systems UUCP ....!mcvax!philapd!dolf Dept. SSP, P.O. Box 245, 7300 AE Apeldoorn, The Netherlands n n n It's a pity my .signature is too small to show you my solution of a + b = c
seanf@sco.COM (Sean Fagan) (02/28/90)
In article <9816@cbmvax.commodore.com> valentin@cbmvax.cbm.commodore.com (Valentin Pepelea) writes: >To my understanding, the CALLM and RTM instructions were really meant to be >operating system intructions only. Can you see any uses for these instructions >in an application program? I don't. I don't know how you reached that conclusion. CALLM and RTM were meant to be useful to people who like Modula-2 (and 3) and the ilk. You know, application level stuff? (Actually, "user-level" describes it better, I guess.) If they were meant to be OS only, they would have been. Fairly easy to do, on a 68k. >I know, I know, the response to that is going to be "we didn't mean to >include the coprocessor". *sigh* No, the response is going to be: "but you wanted it fast, didn't you?" Assuming the 68050, if it comes to be, has enough transistors, it will probably have more of the FP instructions (there's only so much you can do in so much space, you know). -- Sean Eric Fagan | "Time has little to do with infinity and jelly donuts." seanf@sco.COM | -- Thomas Magnum (Tom Selleck), _Magnum, P.I._ (408) 458-1422 | Any opinions expressed are my own, not my employers'.
phil@motaus.UUCP (Phil Brownfield) (03/01/90)
How to view 68000 family user mode upward object code compatibility depends on whether one sees a difference between instruction set *architecture* and instruction set *implementation*. With an MC68030/MC68882 chipset as the CPU, the implementation of all floating point operations is done in hardware (read "microcode" if you prefer). In the MC68040, the implementation of the simple floating point operations (e.g. FADD, FMUL) is done in hardware, while implementation of the more complex ops (e.g. FSIN, FMOD) is done by software in the F-line emulation exception handler executing in supervisor mode. In either the MC68030/MC68882 chipset or the MC68040/exception handler combination, the underlying implementation is invisible to a user mode programmer. The instruction set architecture available to user mode programmers of either implementation is the same. If this view seems of doubtful usefulness, check out how most current RISC chipsets implement the operations required by the IEEE 754 floating point standard, to pick one of several other examples. MOVE from SR for user mode programs can be emulated fairly easily in the privilege violation exception handler, if a system implementer feels the need and a given chip doesn't support the operation. I guess it could be debated whether CALLM/RTM were retroactively declared not a part of the 68000 family instruction set *architecture*; or whether they were just a feature of the MC68020 MPU and MC68851 PMMU chipset *implementation*. >>I know, I know, the response to that is going to be "we didn't mean to >>include the coprocessor". *sigh* > >No, the response is going to be: "but you wanted it fast, didn't you?" More or less this is right. But to clarify: by bringing the FPU onto the 040 the speed of simple FP operations was improved enough that sequences of the 040's simple operations can perform the complex FP operations faster than the MC68882's microcoded implementation. And if you can eliminate silicon without a performance penalty generally you win, because either the chip becomes more buildable or you can apply the silicon to other features. -- Phil Brownfield, Motorola Semiconductor {cs.utexas.edu!oakhill, mcdchg}!motaus!phil Speaking for myself, not my employer
dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer) (03/02/90)
Another point is that the MC68040 doesn't support co-processors anymore. The MMU & FP are on-chip but there is no external interface to another (custom made and/or proprietary) co-processor. Isn't this a problem ? Or was the co-processor interface only for one customer which decided later on not to use it (as with the CALLM/RTM) ? I do not know of any co-processor other than MC68851, MC68881/MC68882 but it could be possible they exist (like a complex co-processor, graphics or X/Window co-processor). On the other hand I once heard of a system which used more than one MC68881 (so each process has its own MC68881, thus saving the context saving on a process context switch). -- Dolf Grunbauer Tel: +31 55 433233 Internet dolf@idca.tds.philips.nl Philips Telecommunication and Data Systems UUCP ....!mcvax!philapd!dolf Dept. SSP, P.O. Box 245, 7300 AE Apeldoorn, The Netherlands n n n It's a pity my .signature is too small to show you my solution of a + b = c