This package is Chuck Moore's colorForth and some stuff I wrote to convert
the bulk of it to osimplay. MASM is INTeL syntax, and Chuck is Chuck, so
this is a lot worse than converting e.g. gcc output to osimplay. At the
point it's at at the moment, Aug 23 2003, it's probably of some use as
documentation for colorForth, and of course osimplay.

unmasm is a Bash script that does the bulk of converting Chuck's MASM to
osimplay. It converts to source/dest also. The "top" file does the 3 files
making up the original colorForth sources. The conversion is not 100%.
Some MASM directives need to be removed or commented out. Negative
integers are left ala

	- 4
			and need to be re-connected. boot.osim needs an 
	allot 0x7c00
			at the H=0. 

I added the rpn word to osimplay to handle Chuck's code, particularly the
data statements that appear to be the hand-coded parts of Chuck's
colorForth dictionary. By hand-coded I mean bitwise. This is probably the
non-primitives. This suggested that an rpn word would be useful in
osimplay generally, so the osimplay with rpn in it is included.

Chuck uses some of the things I only implement in osimplay as composites
with rep in "plurals" as onezies. That is, Chuck uses lods* and stos* and
even scas* without rep. Those are assembled with ab rather than adding
them to osimplay, because they are the kind of 386-ism I'd prefer to
de-emphasize in osimplay. Chuck thus demonstrates a nifty way to implement
a stack on the 386, but it's still just beyond being worth the namespace
in osimplay.

There's usually a diminishing-returns point with converters where you just
clean up the odd bits by hand. That's the phase between the *.unm files
top/unmasm generates and the *.osim files. then one does a

	. osimplay
	osimplay color.osim

and maybe tries to boot the thing. One of the reasons I'm putting this up
before I myself have it booted is I'm not sure I have the hardware for it
anyway, so some feedback would be appreciated.




















masm syntax basics

; comment
label:
ddddh	hex
ddddo	octal
@@:	unnamed label
INTeL=	 op dest, source
data words use commas



I started converting Chuck Moore's colorForth to osimpa a while back, but
parts of MASM looked pretty obscure to me. osimpa improved into osimplay,
and I looked at colorForth again, and the only thing I don't get, I think,
is the 'offset' tokens Chuck uses. So I went at it again with ed and Pico,
and thought, what the heck, for this much effort I can have a converter.
One evening later I have about a third of one, in Bash, surprisingly
enough. 

First I bust the MASM source up so every letter that means something
individually, like : at the end of a token, is spaced apart from other
tokens, as is the case for all tokens in osimplay, and Forth, BTW.  Then I
do a wad of name changes. I've only done the ones that occur in Chuck's
boot code file, and not all of those because e.g. rep movsd is
syntactially different in osimplay. There's a bit of syntax to tl(), with
the local labels keeping a current one current, but there's a lot more to
do. osimplay memrefs are very different than INTeL/MASM, and I'm probably
going to go source/dest also, rather than just transliterating comma to
'from'. Then there's the MASM numeric literal composition stuff, which
Chuck goes nuts with in COLOR.ASM, which see below.

Bash case constructs are Very Very Powerful, each case being a match
string. Almost like ml patterns. For one thing, the case patterns mean I
didn't need firstchar() and so on. One of the revelations of the evening
was Bash set -f which cleaned up a nightmare with expanding * into all the
filenames in cwd. That came up while doing the array in t0(). The lexer
stuff depends on some curly parameter expansion. After that, the problems
of converting asm to asm are pretty tame. Particularly if you can live
with cleaning up stunts like Chuck's

org $-2

by hand (unmasm now handles that itself). Chuck does that to assemble
use16 code in a use32 MASM 'segment', apparently. Clever, but I just
change \$cell in osimplay.


There's no way I'm doing the Mickeysoft Thing required to read the MASM
docs, so if there are any Masm victims about, here's the couple of things
I could stand to have explained...

	ALIGN 4
	    me dd offset God

'me' is a label? What's the difference between  label  and label:  ?
What's 'offset'?
(Chuck's offset from God?)

{I got that explained by Chuck himself. It allows MASM to use an address
as a number.  Microsoft sells stuff like that. Note also that Chuck's
offset from God vanishes in osimplay.)

       dd (((177o shl 7+140o)shl 7+146o)shl 7+142o)shl 4 ; ?dup

I take it that numerical atrocity is equivalent to something like ...

#	$((((((((\0177<<7)+\0140)<<7)+\146)<<7)+\0142)<<4))

in Bash? i.e. shl is up-significance shift, and binds before + ?
And 177o is octal? (Obvious, but anyway...)


The shell is not bad for sech crap. Translators are about strings. Think
strings and the shell isn't bad.

The difference between unmasm and a compiler is the depth of parsing. I
have to handle one line at a time, at most, and I only look at a whole
line in swapargs. asmacs() e.g. is single-token.  No recursive descents
into AI hell. The inspired student may note with some interest that Bash
recurses nicely though. pffffheh. Hello World in about an hour! Real
hacking. Hello World in C was only about 15 minutes on a C64. I think I
need sleep.

The overall layout IS like a compiler like Gcc at a hugely lower level,
with all the passes. You could stick optimizers in here. The only routines
at this writing (80% of what I want?) that aren't single entire file-scale
passes are chom, ec, syncode, bisyncode, and unmasm is every pass. Piping
between routines like each one is a command (which it is) is modular, and
slow I suppose. If you try to combine things it gets untenable fast,
though. The defenses from the slowness are the case constructs in the
passes that try to early-out when possible, which for some passes is a
lot, and a multi-tasking OS :o)



Rick Hohensee

