Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site peora.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!whuxl!houxm!vax135!petsd!peora!jer
From: jer@peora.UUCP (J. Eric Roskos)
Newsgroups: net.arch,net.micro.68k
Subject: Re: M680*0 "small model"
Message-ID: <1071@peora.UUCP>
Date: Sat, 15-Jun-85 21:52:09 EDT
Article-I.D.: peora.1071
Posted: Sat Jun 15 21:52:09 1985
Date-Received: Mon, 17-Jun-85 04:39:32 EDT
References: <167@mot.UUCP> <1069@peora.UUCP>
Organization: Perkin-Elmer SDC, Orlando, Fl.
Lines: 23
Xref: watmath net.arch:1398 net.micro.68k:921

> It sounds to me like what the 68000 needs is an optimizing assembler.
> On Perkin-Elmer 3200 series computers there are several addressing
> modes, using from 2 to 6 bytes per instruction. The assembler
> automatically figures the best addressing mode and generates the
> appropiate object code.

Actually the better 8086 assemblers do this.  And in the days back when I
used to write 8086 assemblers I used an algorithm very similar to the one
you're describing to do it.  It is fairly complicated to do, because the
iterative algorithm can loop forever in pathological cases if you don't
keep track of what you're doing.

Well, actually the Intel assemblers do even more than that... some mnemonics,
such as MOV, can generate 8 or so different opcodes, depending on the
operands, before you even get to all the small details like the addressing
modes, selecting the destination operand and size of immediates, etc.
-- 
Full-Name:  J. Eric Roskos
UUCP:       ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer
US Mail:    MS 795; Perkin-Elmer SDC;
	    2486 Sand Lake Road, Orlando, FL 32809-7642

	   "Gnyx gb gur fhayvtug, pnyyre..."