NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/sys/atari/st/tech/4653

Internet Message Format | 1992-09-01 | 3.7 KB

Path: sparky!uunet!mcrware!mwca!bill
From: [e-mail] (Bill Sheppard)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Falcon 030 ? nah wait the 040 !
Message-ID: <[e-mail]>
Date: 1 Sep 92 21:08:35 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Microware Systems Corp., Santa Clara, Ca.
Lines: 59

In <[e-mail]> [e-mail] (Mike Healy) writes:

>I work on 680x0 VME based realtime systems. We have just gone from
>Force CPU-30s (68030) to CPU-40s (68040) with no changes to our
>code except recompiling with the proper switches. Of course we
>use C (gcc actually)! I imagine assembler would involve a lot
>of changes. I also think Wind River Systems had to make a lot
>of changes to vxWorks, the realtime OS we use, so that it would
>run on the CPU-40. How many of those changes were dictated by
>the 68040 processor and how many by other parts of the board,
>I don't know.

Actually, not much effort is _required_ to migrate from the 68030 to the
68040.  I work for Microware Systems, the makers of OS-9 (a competitor of
VxWorks), and we also support the CPU-30 and CPU-40.  The operating system
really doesn't need to worry much about the differences, although to optimize
for the 040 you want to take advantage of its different cache architecture (we
do).  The compiler maker (at Microware we do our own compiler technology, Wind
River has customers use third-party or other compilers) needs to be concerned
with differences in the floating point hardware and, for optimum performance,
instruction set changes. (The 68882, typically designed in with a 68030, does
both floating point and transcendental/trig functions in hardware, while the
68040's built-in FPU only does floating point necessitating software emulation
for the transcendental/trig functions.)  However, in most cases the 68040 is
100% backwards compatible with the 68030, so object code need not be
recompiled.  The Force CPU-40 does have some different support hardware than
the CPU-30, so those particular drivers would need to be modified.

>We have noticed a definite speedup using the '40s in our
>applications, but I have heard some horror stories of some
>applications running the same or slower than '30s ( the math
>functions not supported by the onboard FPU and hence microcoded
>appear to be the culprits), but these might have been more
>prevalent in the first ports to '40 boards (remember, a 68040
>processor board has more components, and possible problems, than
>just a 68040).

If there is lots of trigonometric code in your application you may find a
68040 to be slower than a 68030/68882 because the internal coprocessor can't
directly handle the transcendentals.  (The 68060 is supposed to fix this.)
Other code, including normal floating point, will be faster on the 68040.

>At any rate, I don't think every C application would have to be
>recoded to run on a '40, but assembler would be a different
>story and also the more an application embedded itself in the
>current hardware architecture, the more changes needed (and
>a lot of those nifty games and graphics seem tightly embedded,
>don't they?)

Neither assembler nor C code should need recompilation, as long as there are
no direct trig calls.  Again, however, your compiler may be able to more
highly optimize code for a 68040 than a 68030 if you _do_ recompile.

Bill
--
 ##############################################################################
 # Bill Sheppard  --  Western Regional Sales Manager  --  [e-mail] #
 # Microware Systems Corporation -- OS-9 / OS-9000 / CD-RTOS -- [phone] #
 ############## Opinions expressed are my own and usually wrong ###############