Drool@cup.portal.com (Paul James Coene) (11/30/88)
In article <1961@crete.cs.glasgow.ac.uk> orr@cs.glasgow.ac.uk (Fraser Orr) writes: >In article <729@convex.UUCP> dodson@mozart.UUCP (Dave Dodson) writes: >>I believe it is important to learn assembly language for some computer >>because that is how you learn how computers _really_ work. This knowledge >>can help you program better in any language. > I tend to agree wholeheartedly with Fraser on this one. Have you ever tried to help someone who has only a base knowledge of HLLs under his belt, when they are trying to debug a debug a C program? Concepts such as the stack, what a core dump is, even explaining pointers is tough when the basics gained from exposure to assembler is lacking. I certainly don't profess to be an assembler wizard, but having some basics behind me has been invaluable. ---- Has anyone seen my staff? - Drool Rockworm ---
elg@killer.DALLAS.TX.US (Eric Green) (12/01/88)
in article <11915@cup.portal.com>, Drool@cup.portal.com (Paul James Coene) says: > In article <1961@crete.cs.glasgow.ac.uk> orr@cs.glasgow.ac.uk > (Fraser Orr) writes: >>In article <729@convex.UUCP> dodson@mozart.UUCP (Dave Dodson) writes: >>>I believe it is important to learn assembly language for some computer >>>because that is how you learn how computers _really_ work. This knowledge >>>can help you program better in any language. > even explaining pointers is tough when the basics gained > from exposure to assembler is lacking. I certainly don't profess to be an > assembler wizard, but having some basics behind me has been invaluable. Ah yes, time to trot out one of my standards, once again (usually, it's on comp.edu, but...). Anyhow, I'll have to agree about the pointers/assembly language correlation. What I seem to have found, among those I know who don't know the difference between "Vax" and "Unix", is that they view pointers as "magic" things that damnedably difficult to use because they do "weird" things. Whereas anybody with assembly language under their belt knows darn well that a pointer is just an address, and that you can follow them by dereferencing ("you mean it's just like loading it into R0 and doing indirect? GEE!"). I have long advocated that programmers need to know more than how to feed Pascal and "C" to a "black box" that spits out answers, to the extent of saying that 1st year CS majors should take digital logic and microprocessors as a corequisite to the usual "bang Pascal into the computer" introductory course. If you don't know the contents of that "black box", if you don't know HOW it spits out those answers, a) your sense of curiousity is seriously lacking, and b) don't be surprised if you're lost when your "black box" suddenly starts spitting out wrong answers. As for me, personally: I avoid using assembly language like the plague. I've had to write large assembly-language programs for 8-bit microcomputers, and liken it to getting teeth drilled insofar as enjoyment goes. Now that I'm programming a 68000-based machine, I'm glad I don't need to go all the way to assembler. BUT, I do find it useful to look at the assembly-language output of my compiler, occasionally... especially when I'm doing something silly like, uhm, "**(xyz[5])++" (I'm paranoid... when I write a bogosity, I want to make sure it does EXACTLY what I want it to do). -- Eric Lee Green ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg Snail Mail P.O. Box 92191 Lafayette, LA 70509
anderson@ncrcce.StPaul.NCR.COM (Joel Peter Anderson) (12/01/88)
As a user of both high level languages, applications, and assembler I have to
say that in my work (telecommunications software) even though I use C for
a lot of my work I have to know assembler to 1)figure out why the program is
not behaving as I expected and 2) the best way C generates the best code. I
learned assembler in college on a Macro11 simulator (no one wanted to trust
us on the mainframe with real machine language, I guess) and found that
somewhat useful. If I never had to write real assembler it would have been
enough. (we wrote an assembler in Macro11 and used it to assemble itself).
Actually my own experience with an assembler on my own computer (a VIC20 at the
time) was far more practical and meaningful when I had to teach myself BAL.
Now to the point: most people don't really need to know the guts of assembler.
They can program Forth, Lisp, BASIC or C and never look inside the box. On the
other hand - in order to psychoanalyze the machines (mis)behaviour the mental
model that assembler experience provides (even in simulation) will go a long
way toward lighting the path. So... How about CoreWar? A nice, fun
non-threatening assembler. An interesting HLL programming project (I want to
write one... maybe in FORTH...) it teaches the basics of machine language,
multi-tasking, the internals of an assembler -PLUS - it has a popular
appeal "learn to write your very own virus!". :-)
-------------------------------------------------------------------------
"We know only the strong will survive, But the meek will inherit.
So if you've got a coat of arms, oh friend, I suggest we wear it."
John Mellencamp.
-------------------------------------------------------------------------
anderson@c10sd3.StPaul.NCR.COM |UUCP: {rosevax, crash}!orbit!pnet51!jpa
Joel Peter Anderson |ARPA: crash!orbit!pnet51!jpa@nosc.mil
NCR Comten / Software engineer |INET: jpa@pnet51.cts.com
-------------------------------------------------------------------------carroll@s.cs.uiuc.edu (12/07/88)
/* Written 10:02 pm Dec 5, 1988 by stachour@umn-cs.CS.UMN.EDU in s.cs.uiuc.edu:comp.lang.c */
One of the important parameters is the "size of the program".
When I was working at IBM in the early 1970's, we had an
outstanding "bet" as to whether anyone could outdo the PL/S compiler
on a "non-trivial" program (defined as one that took more than
1K bytes of 360-assembler to write). We had a number of challenges.
We never lost. (...)
/* End of text from s.cs.uiuc.edu:comp.lang.c */
Fascinating. I worked at SubLogic for a summer, and they write *everything*
in assembler. One of their products is FlightSimulator (what MicroSoft puts
their name on and sells as if they wrote it). The object code for it is
far more than 1K long, and no compiler every matched it for speed or
compactness. In fact, one of the reasons for the success of the company is
that the speed critical routines (such as the 3D-2D perspective transforms)
worked so fast. There is *no* way they could have been done in a high-level
language - the abuse of the machine features is amazing. I personally have
written assembly programs for the 3b2 that were re-writes of C code (part
of a class I TA'd), and we generally got a 3-10 times speed up. We had
challenges in class too, and the assembler whipped the compiler every time,
for code much longer than 1K.
Alan M. Carroll "How many danger signs did you ignore?
carroll@s.cs.uiuc.edu How many times had you heard it all before?" - AP&EW
CS Grad / U of Ill @ Urbana ...{ucbvax,pur-ee,convex}!s.cs.uiuc.edu!carrollhenry@utzoo.uucp (Henry Spencer) (12/16/88)
In article <207600012@s.cs.uiuc.edu> carroll@s.cs.uiuc.edu writes: >... One of their products is FlightSimulator (what MicroSoft puts >their name on and sells as if they wrote it). The object code for it is >far more than 1K long, and no compiler every matched it for speed or >compactness... This is arguably an unfair example, since the 80x86 is a model of how to design a machine to make life difficult for compiler writers, unless your program will fit in 64KB. (The 80x86 is fun in other ways too, but the >16-bit pointers are an unrelieved nightmare.) -- "God willing, we will return." | Henry Spencer at U of Toronto Zoology -Eugene Cernan, the Moon, 1972 | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
knudsen@ihlpl.ATT.COM (Knudsen) (12/17/88)
In article <207600012@s.cs.uiuc.edu>, carroll@s.cs.uiuc.edu writes: > Fascinating. I worked at SubLogic for a summer, and they write *everything* > in assembler. One of their products is FlightSimulator (what MicroSoft puts > their name on and sells as if they wrote it). The object code for it is > far more than 1K long, and no compiler every matched it for speed or > compactness. In fact, one of the reasons for the success of the company is > that the speed critical routines (such as the 3D-2D perspective transforms) > worked so fast. There is *no* way they could have been done in a high-level > language - the abuse of the machine features is amazing. I personally have I'd agree with everything the author says. What is really extraordinary is that SubLogic's FS and FS-II have been ported to so many other machines besides the PClones. You can get it for the Color Computer (6809) and some of the 68000 machines, and maybe the Commo-64 and Apple-II (6502). All these micros have features to "abuse" (love that term), but they're all different. A big argument in favor of C is the ease of porting, but SubLogic seems to have ported pretty well even in assembler. I guess the projected sales of FS allowed them to throw enough bodies at the job to get it done. Of course if the origianl 8086 assembly source was well laid out and documented, porting to another assembler is a lot easier than writing from scratch. But you have to discard the old "abuses" and come up with new ones. -- Mike Knudsen Bell Labs(AT&T) att!ihlpl!knudsen "Lawyers are like nuclear bombs and PClones. Nobody likes them, but the other guy's got one, so I better get one too."
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/17/88)
In article <8215@ihlpl.ATT.COM> knudsen@ihlpl.ATT.COM (Knudsen) writes: >What is really extraordinary >is that SubLogic's FS and FS-II have been >ported to so many other machines besides the PClones. My, how quickly we forget. SubLOGIC developed their initial products, including Flight Simulator, exclusively for the Apple II. The original Flight Simulator used monchrome line graphics; it was a big hit. I'm waiting for an Apple IIGS version. Because SubLOGIC built everything the hard way (not only CPU-specific assembly code, but also their own disk file system), it's taking them longer than it would have to produce a new port like that. The real question is, how much of that was really necessary? I haven't tried to figure out their particular methods, but I know of ways to do much of what is needed for Flight Simulator in C, and I know of spiffier flight simulators on real graphics systems that are coded entirely in C.
eichin@athena.mit.edu (Mark W. Eichin) (12/18/88)
Mike Knudsen <att!ihlpl!knudsen> typed <8215@ihlpl.ATT.COM>: >>Of course if the origianl 8086 assembly source was well laid out >>and documented, porting to another assembler is a lot easier than >>writing from scratch. I used to run SubLogic Flight Simulator I on the TRS-80 Model I and III, as well as the Apple II. I'd be *very* surprised to find that the porting base was the 8086 assembler code, since I don't believe the chip was available at the time (I have a very low serial numbered Model I :-). Perhaps <carroll@s.cs.uiuc.edu> can enlighten us, having worked there? Mark Eichin <eichin@athena.mit.edu> SIPB Member & Project Athena ``Watchmaker''
bobmon@iuvax.cs.indiana.edu (RAMontante) (12/19/88)
Thanks, Doug Gwyn, for having some memory... -My, how quickly we forget. SubLOGIC developed their initial products, -including Flight Simulator, exclusively for the Apple II. The original -Flight Simulator used monchrome line graphics; it was a big hit. - -I'm waiting for an Apple IIGS version. Because SubLOGIC built -everything the hard way (not only CPU-specific assembly code, but -also their own disk file system), it's taking them longer than it -would have to produce a new port like that. - -The real question is, how much of that was really necessary? -I haven't tried to figure out their particular methods, but I know -of ways to do much of what is needed for Flight Simulator in C, -and I know of spiffier flight simulators on real graphics systems -that are coded entirely in C. Did the Apple II, or II+, have a reasonably optimizing C compiler back then? I doubt it; I remember them promoting Pascal pretty hard. I know my C-64 didn't have any C compiler at all initially, while it did have FSII. The extant operating systems didn't offer much help, either -- I remember lots of custom drivers for the C-64 disk drive, because the monitor ROM wanted to do bit-serial disk IO at 300bps (with 3 or 4 pointless handshaking lines). Do those real graphics systems use 1MHz 8-bit cpus with 48K of memory? Or 192K mass storage with "start drive motor" signals? (Or even 4.77MHz cpus, with segmented memory in 64K chunks?)
mat@mole-end.UUCP (Mark A Terribile) (12/19/88)
> > ... and they write *everything* in assembler. One of their products is > > FlightSimulator (what MicroSoft puts name on ...). The object code for it > > is far more than 1K long, and no compiler every matched it for speed or > > compactness. ... There is *no* way they could have been done in a > > high-level language - the abuse of the machine features is amazing. ... > ... > What is really extraordinary is that SubLogic's FS and FS-II have been > ported to so many other machines besides the PClones. ... All these micros > have features to "abuse" (love that term), but they're all different. ... > I guess the projected sales of FS allowed them to throw enough bodies at > the job to get it done. Of course if the original ... source was well laid > out and documented, porting ... is a lot easier than writing from scratch. > But you have to discard the old "abuses" and come up with new ones. Bear in mind something else: If the code is well structured at every level, with a minimum of hooks from place to place, intelligible data structures (NOT an oxymoron even in assembler) and a CLEAR, WELL-DEFINED PURPOSE for every section of code, recoding from scratch to match the original design is a reasonable task. One of the critical parts of a project like that is understanding both the target machine and the information that must be represented in the data structures so that they can be used efficiently (whether by compiler-quality code or by ``abuses'') by ALL the code that must deal with them. If the ugliness can be pushed down into modules designed for speed, and the overall control is seperated from the low-level control that must deal with the grunge, it's no longer an impossible task. This, by the way, is NOT restricted to assembler: one of the grave weaknesses that I have seen in many ``not-yet-expert'' programmers is the inability to see how the data structures will affect the code that must use them, and it's as much a problem in C or in Pascal. In fact, it's worse in Pascal. That language's crippled expression syntax and data access capabilities make it impossible to write reasonable code unless you get the data structures perfect--an impossibility in code to which major new ``features'' must be added over time, along with new operations on the data structures. Perhaps the biggest help I know to meeting the ``CLEAR, WELL-DEFINED PURPOSE'' criterion is to write the code as if I would have to write a manual page that would be tested for both clarity and correctness. -- (This man's opinions are his own.) From mole-end Mark Terribile
mcdonald@uxe.cso.uiuc.edu (12/19/88)
-My, how quickly we forget. SubLOGIC developed their initial products, -including Flight Simulator, exclusively for the Apple II. The original -Flight Simulator used monchrome line graphics; it was a big hit. - -I'm waiting for an Apple IIGS version. Because SubLOGIC built -everything the hard way (not only CPU-specific assembly code, but -also their own disk file system), it's taking them longer than it -would have to produce a new port like that. - -The real question is, how much of that was really necessary? -I haven't tried to figure out their particular methods, but I know -of ways to do much of what is needed for Flight Simulator in C, -and I know of spiffier flight simulators on real graphics systems -that are coded entirely in C. On an Apple II or an original PC, with 48 K memory and tiny disks, yes, not only was assembly necessary, it probably was stuffed to the gills with the most arcane hacks ever thought of. I still think that the original FS was the most impressive program I have ever seen. Certainly it impresses more than the simulator I saw on a friends Iris 4 super graphics workstation. The ONLY thing going on that is the supersmooth graphics. I've written molecular dynamics graphics simulations on PC's, and on anything less than a 16 MHz 386 they need to have the actual graphics part done in mostly in assembler, and extremely carefully hand coded at that. The rest is in C; on a good 386 all could be in C (on a PC of course, where the C compiler puts outp instructions inline. On a 386 PC running Unix - oh my God, I seriously doubt if it could be done. I know that I tried originally to use a VAX780 and failed miserably due to no bitmapped graphics.) Doug McDonald
carroll@s.cs.uiuc.edu (12/22/88)
RE: SubLogic & FS If I remember my company history correctly, the very original version was done on a Z80-S100 system, but the first commercial release was indeed for the Apple. As has been mentioned, the source code is highly partitioned, and so is not the nightmare you might imagine. The current porting base is '86 code, but that is a (relatively) recent change. The graphics are actually written in a language called 'RTAL' (Real Time Animation Language), a SubLogic internal. To get graphics up, you have to build an RTAL engine, which is always hand-crafted, and then most of the display is done. Porting is done by machine experts, programmers who are masters of the arcana of a particular machine. Bruce Artwick, the wizard who made SubLogic, is amazing beyond words in assembler skills, and is responsible for the high quality of the original version, and the assembler-philia that permeates the company. Also, as was pointed out, in the days that FS first came out, doing real-time 3D graphics was simple impossible using a high level langauge. Today, it might be a different story, but you have to keep in mind that the largest installed base is not the new whiz-bang 25MHz '386 boxes, but old PC's and Apple's. 10 years from now, it could be a different world, and I would certainly agree that high-level languages are the rising power, and assembler the fading giant.