Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!samsung!sol.ctr.columbia.edu!src.honeywell.com!msi.umn.edu!cs.umn.edu!thornley From: thornley@cs.umn.edu (David H. Thornley) Newsgroups: comp.lang.misc Subject: Re: Aggressive optimization Message-ID: <1990Oct30.221510.4392@cs.umn.edu> Date: 30 Oct 90 22:15:10 GMT References: <2060@aber-cs.UUCP> <65592@lanl.gov> <2677@l.cc.purdue.edu> <12175@ganymede.inmos.co.uk> <16101@csli.Stanford.EDU> Organization: University of Minnesota, Minneapolis - CSCI Dept. Lines: 25 In article <16101@csli.Stanford.EDU> poser@csli.stanford.edu (Bill Poser) writes: >In article <12175@ganymede.inmos.co.uk> conor@inmos.co.uk (Conor O'Neill) writes: >>When I was first taught any computer science, I was taught that an assembler >>performed a one-to-one translation of assembly language mnemonics to >>machine instructions. I like, and can understand, that definition. > >>Am I the only programmer who wishes that MIPS hadn't "corrupted" the word >>"assembler", but had used some other term instead? > >[VAX and DEC 20 references omitted] If my memory serves, the IBM 650 had a Symbolic Optimizing Assembly Program (yep, they used the acronym) that rearranged the machine-language instructions to a good order so that they can be executed faster on the drum memory. The concept that an assembler can mess with the translation is a lot older than some of the people reading it. (Disclaimer: I'm not sure it was an IBM 650, but it was on an IBM with drum main memory, which puts it back in the '50s. For an education in how people worked with such drum memories, go to alt.folklore.computers and ask about Mel. :-) DHT