From: kochmar@sei.cmu.edu (John Kochmar)
Subject: Re: Program in assembly...NOT! (was Re: Ca
Organization: The Software Engineering Institute
Date: Fri, 18 Dec 1992 17:41:47 EST


In article <1992Dec18.201407.623@brtph560.bnr.ca>, andrewg@brtph346.BNR.CA (Krishna Kushwaha P205) writes:
|> How can you compare the CPU in the Genesis with those in the SNES or TG-16.
|> the TG-16 has a 6502, the SNES a 16bit version of the 6502 running at 3Mhz.
|> The Genesis on the other hand has an 8Mhz 68000 which is 2-3 times faster. 
|> It also has a nice instruction set and 32bit internal registers. The older 
|> Macs use the same CPU as to several older UNIX machines. The first
|> implementation of Postscript was on a controller based on this CPU. There
|> are plenty of good 'C' compilers available for it. The only problem with
|> using an HLL on the Genesis is cartridge space. Assembler code is smaller. 
|> Most of the games I have for the Genesis are plenty fast enough.
|> 
|> Andrew Grant

13-14 years ago (Gawd, am I that old ;^), I worked with a EE on a
Fortran program that compiled into 8K of memory, ran on a PDP-11/34
(considerably slower than the current SNES processor) that ran in real
time and collected data from mine explosions; lots of data from sensors
placed all around (inside and out) a concrete reinforced experimental
mine.  The program collected the data, correleated it based on the
position of the sensors, and stored the correlated data for an event
that lasted less than 2 seconds.  And, because of the hazard of
creating a mine explosion (an impressive event, I must tell you), you
had to get all of your data the first (or second, if you were lucky)
time.

Now, you might argue that Fortran (Fortran IV, in this case) is not an
appropriate HLL for producing games, or that a C object is by its very
nature larger than a fortran object.  And yes, there were parts of the
OS that the fortran program depended on that were written in Assembly.
But, we were able to develop a real-time program that had to collect a
great deal of data from dozens of input sensors (I think we had 32
sensors placed, but it could have been 64), in real time, for an event
that lasted less than 2 seconds, debugged and logically correct (you
can't play-test a mine explosion, much as you might like to :^) in less
than 2 weeks with a slower processor and less memory to work with than
even the nes.  I do not believe we could have done as well by writing
directly in assembly.

Compilers don't have to generate huge objects.  The fact that some do
because of a trend towards cheaper hardware at the expense of object
size does not mean that all HLL's have to.  Don't confuse the size of
the display data with the code necessary to push that data around.  The
size of the code used to control the data is small by comparison (this 
is probably not true for all games, but is certainly true for games like
SFII which require around a meg to store.)

John


-----------------------------------------------------------------------------
John Kochmar		 | Estimated amount of glucose used by an adult human
kochmar@sei.cmu.edu	 | brain each day, expressed in M&Ms: 250
SEI Computing Facilities |			-Harper's Index, October 1989