MAKING A QBASIC ASSEMBLER: WORKING DEFENITION

For purpose of reference I consider it to be nice to have 
something of a working definition of what it is I am doing 
when I am talking about making a QBASIC assembler.

MOVIVATION: WHY SO ?

You might ask me why I would make an assembler while there
is already MASM, TASM and the freely available NASM and
VALARROW, and shareware A86 available. And on top of that 
almost everyone already has DEBUG at his disposal...

Let me state from offset one thing very clear: the main 
purpose is NOT (like NASMs is) to make a BETTER one. Apart
from lacking the skill and experience to do so, it was 
simply not why I started it in the first place.

Being something of a hobby programmer and frequenter of 
both asm.x86 and basic.misc NG for almost a year now, I
realized that both the concepts 'compiler' and 'assembler'
started to get vague, sometimes even magic, for me.
I took the actual job of assembling and compiling for granted
as the generation of a obj/exe/com file by the assembler/compiler 
as some deus ex machina. I also realized that in the NGs there 
was often the suggestion of complexity beyond belief WHEN compiler/ 
assembler specific issues where discussed. And in the end that WERE 
the things that triggered my interest. 

I worked my way through the compiler tutorial of Jack Crenshaw
(http://iecc.com/compilers/crenshaw/)and realized it was not as 
impossibly difficult as I thought. To make this feeling more solid
I translated large parts the tutorial to QBASIC, and even made
a first tiny compiler in QBASIC. That was mainly in the spirit of
making the concept 'compiler' accessable to much more people.
My object there would NOT be a better QBASIC compiler neither, but
much more a core-compiler written in QBASIC with which a huge 
bundle of people can experiment( and link in there wishes) because
they now understand there compiler.
 
Of course I have to admit that my belief is that if such a process
could be put fruitfully of the ground that will in the end result
in a much better QBASIC compiler too, but I will not strive to that,
nor hold my breath for it...
 
While 'compiling' was becoming a statement for me again, 'assembling' 
was still magic: even the compiler relied upon VALARROW for its
obj generation....In addition to that I realized that for most 
basic newsgroup users who did not have payware MASM/TASM at there
disposal the .386 instruction set was not available for inline ASM$
in QBASIC, not because QBASIC can not handle it, but because they
lack the tool to translate .386 code to inline ASM$ statements.
While most QBASIC assemblers still used debug for ASM$ generation 
they lacked the symbol table goodies(labels, variables)from other 
assemblers as well. And of course nor debug nor any other assembler
directly outputs ASM$ inline code. And there was still the 'assembling'
concept.

So that got me started in trying to make something very much alike
Jack Crenshaws tutorial( although without doubt not that good) with
the topic of making an assembler. The main things that I would liked
to adopt from Jack are his Keep It Simple(KISS) filosofy and his 
'explaining while doing' approach. Of course that will make it suffer 
from the same drawbacks like retrograde development( ..).

Anyhow that is what this series of articles will be about: making 
an assembler in QBASIC. So lets process on to a working definition
of the job..


INTRODUCTION: WHAT IS AN ASSEMBLER ?

To keep it very simple I would consider an assembler an
utilitie that has the capacities to translate an assembly 
language his statements into machine language. 

That is the same as to say that the particular assembly
language and the assembler are two parts of the same medal.
There is no sense in an assembler without a language 
definition and vice versa. 

PLATFORM DEFINITION

While there are a lot of possibilities I will stick to
8086 machine language with 32 bit addition.

DEVELOPMENTAL LANGUAGE: QBASIC

Since I think most people can understand QBASIC INTREPRETER
code and its also the HLL which I am fluent at, the most logic 
choice would be indeed QBASIC. That would not make it possible
to make a stand alone assembler of course, but it will make
all the concepts understandable. And transference to a stand
alone assembler could always be done later on..

SPLITTING UP THE JOB.

While it should be pretty clear by know what we are building here
it seems to me necessary to split up the job into handsome parts.
First of all we know that most assemblers output obj or lib code 
instead of only machinebytes like debug. 

Essentially obj or lib code is just machine language with added
symbol table like information( Segment, variable etc information).
I will postpone the job of making obj s until we have the machine
language generation works flawlessly, but its only fair to let you
know I thought.

So that would make our assembler to a machine language generator.
Even the solvation of labels and procedures will be postponed 
until this machine language generation is done. Our machine language
generator will be something like 32 bit debug. It would output
valid 8386 machine language which could be translated to a com file
and to inline ASM$ statements. 
In fact that pretty much describes the commandline of the mg:
     qb2asm infile.asm [/l | /c outfile.com |/ a outfile.bas]
     l= line output mode( line by line assembling to stdout)
     c= com file output mode
     a= asm$ output mode

Happy learning,

Rick(rick@tip.nl)