1893 lines
42 KiB
Text
1893 lines
42 KiB
Text
. \" $Header$"
|
|
.RP
|
|
.ND Dec 1984
|
|
.TL
|
|
.B
|
|
A backend table for the 6500 microprocessor
|
|
.R
|
|
.AU
|
|
Jan van Dalen
|
|
.AB
|
|
The backend table is part of the Amsterdam Compiler Kit (ACK).
|
|
It translates the intermediate language family EM to a machine
|
|
code for the MCS6500 microprocessor family.
|
|
.AE
|
|
.bp
|
|
.DS C
|
|
.B
|
|
THE MCS6500 MICROPROCESSOR.
|
|
.R
|
|
.DE
|
|
.NH 0
|
|
Introduction
|
|
.PP
|
|
Why a back end table for the MCS6500 microprocessor family.
|
|
Although the MCS6500 microprocessor family has an simple
|
|
instruction set and internal structure, it is used in a
|
|
variety of microcomputers and homecomputers.
|
|
This is because of is low cost.
|
|
As an example the Apple II, a well known and width spread
|
|
microprocessor, uses the MCS6502 CPU.
|
|
Also the BBC homecomputer, whose popularity is growing day
|
|
by day uses the MCS6502 CPU.
|
|
The BBC homecomputer is based on the MCS6502 CPU although
|
|
better and stronger microprocessors are available.
|
|
The designers of Acorn computer Industries have probably
|
|
choosen for the MCS6502 because of the amount of software
|
|
available for this CPU.
|
|
Since its width spreaded use, a variaty of software
|
|
will be needed for it.
|
|
One can think of games!!, administration programs,
|
|
teaching programs, basic interpreters and other application
|
|
programs.
|
|
Even do it will not be possible to run the total compiler kit
|
|
on a MCS6500 based computer, it is possible to write application
|
|
programs in a high level language, such as Pascal or C on a
|
|
minicomputer.
|
|
These application programs can be tested and compiled on that
|
|
minicomputer and put in a ROM (Read Only Memory), for example,
|
|
cso that it an be executed by a MCS6500 CPU.
|
|
The strategy of writing testprograms on a minicomputer,
|
|
compile it and then execute it on a MCS6500 based
|
|
microprocessor is used by the development of the back end.
|
|
The minicomputer used is M68000 based one, manufactured by
|
|
Bleasdale Computer Systems Ltd..
|
|
The micro- or homecomputer used is a BBC microcomputer,
|
|
manufactured by Acorn Computer Ltd..
|
|
.NH
|
|
The MOS Technology MCS6500
|
|
.PP
|
|
The MCS6500 is as a family of CPU devices developed by MOS
|
|
Technology [1].
|
|
The members of the MCS6500 family are the same chips in a
|
|
different housing.
|
|
The MCS6502, the big brother in the family, can handle 64k
|
|
bytes of memory, while for example the MCS6504 can only handle
|
|
8k bytes of memory.
|
|
This difference is due to the fact that the MCS6502 is in a
|
|
40 pins house and the MCS6504 has a 28 pins house, so less
|
|
address lines are available.
|
|
.bp
|
|
.NH
|
|
The MCS6500 CPU programmable registers
|
|
.PP
|
|
The MCS6500 series is based on the same chip so all have the
|
|
same programmable registers.
|
|
.sp 9
|
|
.NH 2
|
|
The accumulator A.
|
|
.PP
|
|
The accumulator A is the only register on which the arithmetic
|
|
and logical instructions can be used.
|
|
For example, the instruction ADC (add with carry) adds the
|
|
contents of the accumulator A and a byte from memory or data.
|
|
.NH 2
|
|
The index register X.
|
|
.PP
|
|
As the name suggests this register can be used for some
|
|
indirect addressing modes.
|
|
The modes are explaned below.
|
|
.NH 2
|
|
The index register Y.
|
|
.PP
|
|
This register is, just as the index register X, used for
|
|
certain indirect addressing modes.
|
|
These addressing modes are different from the modes which
|
|
use index register X.
|
|
.NH 2
|
|
The program counter PC
|
|
.PP
|
|
This is the only 16-bit register available.
|
|
It is used to point to the next instruction to be
|
|
carried out.
|
|
.NH 2
|
|
The stack pointer SP
|
|
.PP
|
|
The stack pointer is an 8-bit register, so the stack can contain
|
|
at most 256 bytes.
|
|
The CPU always appends 00000001 as highbyte of any stack address,
|
|
which means that memory locations
|
|
.B
|
|
0100
|
|
.R
|
|
through
|
|
.B
|
|
01FF
|
|
.R
|
|
are permanently assigned to the stack.
|
|
.sp 12
|
|
.NH 2
|
|
The status register
|
|
.PP
|
|
The status register maintains six status flags and a master
|
|
interrupt control bit.
|
|
.br
|
|
These are the six status flags:
|
|
Carry (c)
|
|
Zero (z)
|
|
Overflow (o)
|
|
Sign (n)
|
|
Decimal mode (d)
|
|
Break (b)
|
|
|
|
|
|
|
|
|
|
|
|
The bit (i) is the master interrupt control bit.
|
|
.NH
|
|
The MCS6500 memory layout.
|
|
.PP
|
|
In the MCS6500 memory space three area's have special meaning.
|
|
These area's are:
|
|
.IP 1)
|
|
Top page.
|
|
.IP 2)
|
|
Zero page.
|
|
.IP 3)
|
|
The stack.
|
|
.PP
|
|
MCS6500 memory is divided up into pages.
|
|
These pages consist 256 bytes.
|
|
So in a memory address the highbyte denotes the page number
|
|
and the lowbyte the offset within the page.
|
|
.NH 2
|
|
Top page.
|
|
.PP
|
|
When a MCS6500 is restared it jumps indirect via memory address
|
|
.B
|
|
FFFC.
|
|
.R
|
|
At
|
|
.B
|
|
FFFC
|
|
.R
|
|
(lowbyte) and
|
|
.B
|
|
FFFD
|
|
.R
|
|
(highbyte) there must be the address of the bootstrap subroutine.
|
|
When a break instruction (BRK) occurs or an interrupt takes place,
|
|
the MCS6500 jumps indirect through memory address
|
|
.B
|
|
FFFE.
|
|
.R
|
|
.B
|
|
FFFE
|
|
.R
|
|
and
|
|
.B
|
|
FFFF
|
|
.R
|
|
thus, must contain the address of the interrupt routine.
|
|
The former only goes for maskeble interrupt.
|
|
There also exist a nonmaskeble interrupt.
|
|
This cause the MCS6500 to jump indirect through memory address
|
|
.B
|
|
FFFA.
|
|
.R
|
|
So the top six bytes of memory are used by the operating system
|
|
and therefore not available for the back end.
|
|
.NH 2
|
|
Zero page.
|
|
.PP
|
|
This page has a special meaning in the sence that addressing
|
|
this page uses special opcodes.
|
|
Since a page consists of 256 bytes, only one byte is needed
|
|
for addressing zero page.
|
|
So an instruction which uses zero page occupies two bytes.
|
|
It also uses less clock cycle's while carrying out the instruction.
|
|
Zero page is also needed when indirect addressing is used.
|
|
This means that when indirect addressing is used, the address must
|
|
reside in zero page (two consecutive bytes).
|
|
In this case (the back end), zero page is used, for example
|
|
to hold the local base, the second local base, the stack pointer
|
|
etc.
|
|
.NH 2
|
|
The stack.
|
|
.PP
|
|
The stack is described in paragraph 3.5 about the MCS6500
|
|
programmable registers.
|
|
.NH
|
|
The memory adressing modes
|
|
.PP
|
|
MCS6500 memory reference instructions use direct addressing,
|
|
indexed addressing, and indirect addressing.
|
|
.NH 2
|
|
direct addressing.
|
|
.PP
|
|
Three-byte instructions use the second and third bytes of the
|
|
object code to provide a direct 16-bit address:
|
|
therefore, 65.536 bytes of memory can be addressed directly.
|
|
The commonly used memory reference instructions also have a two-byte
|
|
object code variation, where the second byte directly addresses
|
|
one of the first 256 bytes.
|
|
.NH 2
|
|
Base page, indexed addressing.
|
|
.PP
|
|
In this case, the instruction has two bytes of object code.
|
|
The contents of either the X or Y index registers are added to the
|
|
second object code byte in order to compute a memory address.
|
|
This may be illustrated as follows:
|
|
.sp 15
|
|
Base page, indexed addressing, as illustrated above, is
|
|
wraparound - which means that there is no carry.
|
|
If the sum of the index register and second object code byte contents
|
|
is more than
|
|
.B
|
|
FF
|
|
.R
|
|
, the carry bit will be dicarded.
|
|
This may be illustrated as follows:
|
|
.sp 9
|
|
.NH 2
|
|
Absolute indexed addressing.
|
|
.PP
|
|
In this case, the contents of either the X or Y register are added
|
|
to a 16-bit direct address provided by the second and third bytes
|
|
of an instruction's object code.
|
|
This may be illustrated as follows:
|
|
.sp 10
|
|
.NH 2
|
|
Indirect addressing.
|
|
.PP
|
|
Instructions that use simple indirect addressing have three bytes of
|
|
object code.
|
|
The second and third object code bytes provide a 16-bit address;
|
|
therefore, the indirect address can be located anywhere in
|
|
memory.
|
|
This is straightforward indirect addressing.
|
|
.NH 3
|
|
Pre-indexed indirect addressing.
|
|
.PP
|
|
In this case, the object code consists of two bytes and the
|
|
second object code byte provides an 8-bit address.
|
|
Instructions that use pre-indexed indirect addressing add the contents
|
|
of the X index register and the second object code byte to access
|
|
a memory location in the first 256 bytes of memory, where the
|
|
indirect address will be found:
|
|
.sp 18
|
|
When using pre-indexed indirect addressing, once again wraparound
|
|
addition is used, which means that when the X index register contents
|
|
are added to the second object code byte, any carry will be discarded.
|
|
Note that only the X index register can be used with pre-indexed
|
|
addressing.
|
|
.NH 3
|
|
Post-indexed indirect addressing.
|
|
.PP
|
|
In this case, the object code consists of two bytes and the
|
|
second object code byte provides an 8-bit address.
|
|
Now the second object code byte indentifies a location
|
|
in the first 256 bytes of memory where an indirect address
|
|
will be found.
|
|
The contents of the Y index register are added to this indirect
|
|
address.
|
|
This may be illustrated as follows:
|
|
.sp 18
|
|
Note that only the Y index register can be used with post-indexed
|
|
indirect addressing.
|
|
.bp
|
|
.NH
|
|
What the CPU has and doesn't has.
|
|
.PP
|
|
Although the designers of the MCS6500 CPUs family state that
|
|
there is nothing very significant about the short stack (only
|
|
256 bytes) this stack caused problems for the back end.
|
|
The designers say that a 256-byte stack usually is sufficient
|
|
for any typical microcomputer, this is only true if the stack
|
|
is used only for return addresses of the JSR (jump to
|
|
subroutine) instruction.
|
|
But since the EM machine is suppost to be a stack machine and
|
|
high level languages need the ability of parameters and
|
|
locals in there procedures and function, this short stack
|
|
is unsufficiant.
|
|
So an software stack is implemented in this back end, requiring two
|
|
additional subroutines for stack handling.
|
|
These two stack handling subroutines slow down the processing time
|
|
of a program since the stack is used heavely.
|
|
.PP
|
|
Since parameters and locals of EM procedures are offseted
|
|
from the localbase of that procedure, indirect addressing
|
|
is havily used.
|
|
Offsets are positive (for parameters) and negative (for
|
|
local variables).
|
|
As explaned before the addressing modes the MCS6500 have a
|
|
post indexed indirect addressing mode.
|
|
This addressing mode can only handle positive offsets.
|
|
This raises a problem for accessing the local variables
|
|
I have chosen for the next solution.
|
|
A second local base is introduced.
|
|
This second local base is the real local base subtracted by
|
|
a constant BASE.
|
|
In the present situation of the back end the value of BASE
|
|
is 240.
|
|
This means that there are 240 bytes reseved for local
|
|
variables to be indirect addressed and 14 bytes for
|
|
the parameters.
|
|
.DS C
|
|
.B
|
|
THE CODE GENERATOR.
|
|
.R
|
|
.DE
|
|
.NH 0
|
|
Description of the machine table.
|
|
.PP
|
|
The machine description table consists of the following sections:
|
|
.IP 1.
|
|
The macro definitions.
|
|
.IP 2.
|
|
Constant definitions.
|
|
.IP 3.
|
|
Register definitions.
|
|
.IP 4.
|
|
Token definitions.
|
|
.IP 5.
|
|
Token expressions.
|
|
.IP 6.
|
|
Code rules.
|
|
.IP 7.
|
|
Move definitions.
|
|
.IP 8.
|
|
Test definitions.
|
|
.IP 9.
|
|
Stack definitions.
|
|
.NH 2
|
|
Macro definitions.
|
|
.PP
|
|
The macro definitions at the top of the table are expanded
|
|
by the preprocessor on occurence in the rest of the table.
|
|
.NH 2
|
|
Constant definitions.
|
|
.PP
|
|
There are three constants which must be defined at first.
|
|
The are:
|
|
.IP EM_WSIZE: 11
|
|
Number of bytes in a machine word.
|
|
This is the number of bytes a simple
|
|
.B
|
|
loc
|
|
.R
|
|
instruction will put on the stack.
|
|
.IP EM_PSIZE:
|
|
Number of bytes in a pointer.
|
|
This is the number of bytes a
|
|
.B
|
|
lal
|
|
.R
|
|
instruction will put on the stack.
|
|
.IP EM_BSIZE:
|
|
Number of bytes in the hole between AB and LB.
|
|
The calling sequence only saves LB on the stack so this
|
|
constant is equal to the pointer size.
|
|
.NH 1
|
|
Register definitions.
|
|
.PP
|
|
The only important register definition is the definition of
|
|
the registerpair AX.
|
|
Since the rest of the machine's registers Y, PC, ST serve
|
|
special purposes, the code generator cannot use them.
|
|
.NH 2
|
|
Token definitions
|
|
.PP
|
|
There is a fake token.
|
|
This token is put in the table, since the code generator generator
|
|
complains if it cannot find one.
|
|
.NH 2
|
|
Token expression definitions.
|
|
.PP
|
|
The token expression is also a fake one.
|
|
This token expression is put in the table, since the code generator
|
|
generator complains if it cannot find one.
|
|
.NH 2
|
|
Code rules.
|
|
.PP
|
|
The code rule section is the largest section in the table.
|
|
They specify EM patterns, stack patterns, code to be generated,
|
|
etc.
|
|
The syntax is:
|
|
.IP code rule:
|
|
EM pattern '|' stack pattern '|' code '|'
|
|
stack replacement '|' EM replacement '|'
|
|
.PP
|
|
All patterns are optional, however there must be at least one
|
|
pattern present.
|
|
If the EM pattern is missing the rule becomes a rewriting
|
|
rule or a
|
|
.B
|
|
coercion
|
|
.R
|
|
to be used when code generation cannot continue because of an
|
|
invalid stack pattern.
|
|
The code rules are preceeded by the word CODE:.
|
|
.NH 3
|
|
The EM pattern.
|
|
.PP
|
|
The EM pattern consists of a list of EM mnemonics followed by
|
|
a boolean expression. Examples:
|
|
.sp 1
|
|
.br
|
|
.B
|
|
loe
|
|
.R
|
|
.sp 1
|
|
will match a single
|
|
.B
|
|
loe
|
|
.R
|
|
instruction,
|
|
.sp 1
|
|
.br
|
|
.B
|
|
loc loc cif
|
|
.R
|
|
$1==2 && $2==8
|
|
.sp 1
|
|
is a pattern that will match
|
|
.sp 1
|
|
.br
|
|
.B
|
|
loc
|
|
.R
|
|
2
|
|
.br
|
|
.B
|
|
loc
|
|
.R
|
|
8
|
|
.br
|
|
.B
|
|
cif
|
|
.R
|
|
.sp 1
|
|
and
|
|
.sp 1
|
|
.br
|
|
.B
|
|
lol
|
|
inc
|
|
stl
|
|
.R
|
|
$1==$3
|
|
.sp 1
|
|
will match for example
|
|
.sp 1
|
|
.br
|
|
.B
|
|
lol
|
|
.R
|
|
6
|
|
.br
|
|
.B
|
|
inc
|
|
.R
|
|
.br
|
|
.B
|
|
stl
|
|
.R
|
|
6
|
|
.sp 1
|
|
A missing boolean expession evaluates to TRUE.
|
|
.PP
|
|
The code generator will match the longest EM pattern on every occasion,
|
|
if two patterns of the same length match the first in the table
|
|
will be chosen, while all patterns of length greater than or equal
|
|
to three are considered to be of the same length.
|
|
.NH 3
|
|
The stack pattern.
|
|
.PP
|
|
The only stack pattern that can occur is R16, which means that the
|
|
registerpair AX contains the word on top of the stack.
|
|
If this is not the case a coersion occurs.
|
|
This coersion generates a "jsr Pop", which means that the top
|
|
of the stack is popped and stored in the registerpair AX.
|
|
.NH 3
|
|
The code part.
|
|
.PP
|
|
The code part consists of three parts, stack cleanup, register
|
|
allocation, and code to be generated.
|
|
All of these may be omitted.
|
|
.NH 4
|
|
Stack cleanup.
|
|
.PP
|
|
When generating something like a branch instruction it might be
|
|
needed to empty the fake stack, that is, remove the AX registerpair.
|
|
This is done by the instruction remove(ALL)
|
|
.NH 4
|
|
Register allocation.
|
|
.PP
|
|
If the machine code to be generated uses the registerpair AX,
|
|
this is signaled to the code generator by the allocate(R16)
|
|
instruction.
|
|
If the registerpair AX resides on the fake stack, this will result
|
|
in a "jsr Push", which means that the registerpair AX is pushed on
|
|
the stack and will be free for further use.
|
|
If registerpair AX is not on the fake stack nothing happens.
|
|
.NH 4
|
|
Code to be generated.
|
|
.PP
|
|
Code to be generated is specified as a list of items of the following
|
|
kind:
|
|
.IP 1)
|
|
A string in double quotes("This is a string").
|
|
This is copied to the codefile and a newline ('\n') is appended.
|
|
Inside the string all normal C string conventions are allowed,
|
|
and substitutions can be made of the following sorts.
|
|
.RS
|
|
.IP a)
|
|
$1, $2 etc. These are the operand of the corresponding EM
|
|
instructions and are printed according to there type.
|
|
To put a real '$' inside the string it must be doubled ('$$').
|
|
.IP b)
|
|
%[1], %[2.reg], %[b.1] etc. these have there obvious meaning.
|
|
If they describe a complete token (%[1]) the printformat for
|
|
the token is used.
|
|
If they stand fo a basic term in an expression they will be
|
|
printed according to their type.
|
|
To put a real '%' inside the string it must be doubled ('%%').
|
|
.IP c)
|
|
%( arbitrary expression %). This allows inclusion of arbitrary
|
|
expressions inside strings.
|
|
Usually not needed very often, so that the akward notation
|
|
is not too bad.
|
|
Note that %(%[1]%) is equivalent to %[1].
|
|
.RE
|
|
.NH 3
|
|
stack replacement.
|
|
.PP
|
|
The stack replacement is a possibly empty list of items to be
|
|
pushed on the fake stack.
|
|
Three things can occur:
|
|
.IP 1)
|
|
%[1] is used if the registerpair AX was on the fake stack and is
|
|
to be pushed back onto it.
|
|
.IP 2)
|
|
%[a] is used if the registerpair AX is allocated with allocate(R16)
|
|
and is to be pushed onto the fake stack.
|
|
.IP 3)
|
|
It can also be empty.
|
|
.NH 3
|
|
EM replacement.
|
|
.PP
|
|
In exeptional cases it might be useful to leave part of the an EM
|
|
pattern undone.
|
|
For example, a
|
|
.B
|
|
sdl
|
|
.R
|
|
instruction might be split into two
|
|
.B
|
|
stl
|
|
.R
|
|
instructions when there is no 4-byte quantity on the stack.
|
|
The EM replacement part allows one to express this.
|
|
Example:
|
|
.sp 1
|
|
.br
|
|
.B
|
|
stl
|
|
.R
|
|
$1
|
|
.B
|
|
stl
|
|
.R
|
|
$1+2
|
|
.sp 1
|
|
The instructions are inserted in the stream so they can match
|
|
the first part of a pattern in the next step.
|
|
Note that since the code generator traverses the EM instructions
|
|
in a strict linear fashion, it is impossible to let the EM
|
|
replacement match later parts of a pattern.
|
|
So if there is a pattern
|
|
.sp 1
|
|
.br
|
|
.B
|
|
loc
|
|
stl
|
|
.R
|
|
$1==0
|
|
.sp1
|
|
and the input is
|
|
.sp 1
|
|
.br
|
|
.B
|
|
loc
|
|
.R
|
|
0
|
|
.B
|
|
sdl
|
|
.R
|
|
4
|
|
.sp 1
|
|
the
|
|
.B
|
|
loc
|
|
.R
|
|
0
|
|
will be processed first, then the
|
|
.B
|
|
sdl
|
|
.R
|
|
might be split into two
|
|
.B
|
|
stl
|
|
.R
|
|
's but the pattern cannot match now.
|
|
.NH 3
|
|
Move definitions.
|
|
.PP
|
|
This definition is a fake. This definition is put in the
|
|
table, since the code generator generator complains if it
|
|
cannot find one.
|
|
.NH 3
|
|
Test definitions.
|
|
.PP
|
|
Test definitions aren't used by the table.
|
|
.NH 3
|
|
Stack definitions.
|
|
.PP
|
|
When the generator has to push the registerpair AX, it must
|
|
know how to do so.
|
|
The machine code to be generated is defined here.
|
|
.NH 1
|
|
Some remarks.
|
|
.PP
|
|
The above description of the machine table is
|
|
a description of the table for the MCS6500.
|
|
It uses only a part of the possibilities which the code generator
|
|
generator offers.
|
|
For a more precise and detailed description see [2].
|
|
.DS C
|
|
.B
|
|
THE BACK END TABLE.
|
|
.R
|
|
.DE
|
|
.NH 0
|
|
Introduction.
|
|
.PP
|
|
The code rules are divided in 15 groups.
|
|
These groups are:
|
|
.IP 1.
|
|
Load instructions.
|
|
.IP 2.
|
|
Store instructions.
|
|
.IP 3.
|
|
Integer arithmetic instructions.
|
|
.IP 4.
|
|
Unsigned arithmetic instructions.
|
|
.IP 5.
|
|
Floating point arithmetic instructions.
|
|
.IP 6.
|
|
Pointer arithmetic instructions.
|
|
.IP 7.
|
|
Increment, decrement and zero instructions.
|
|
.IP 8.
|
|
Convert instructions.
|
|
.IP 9.
|
|
Logical instructions.
|
|
.IP 10.
|
|
Set manipulation instructions.
|
|
.IP 11.
|
|
Array instructions.
|
|
.IP 12.
|
|
Compare instructions.
|
|
.IP 13.
|
|
Branch instructions.
|
|
.IP 14.
|
|
Procedure call instructions.
|
|
.IP 15.
|
|
Miscellaneous instructions.
|
|
.PP
|
|
From all of these groups one or two typical EM pattern will be explained
|
|
in the next paragraphs.
|
|
Comment is placed between /* and */ (/* This is a comment */).
|
|
.NH
|
|
The instructions.
|
|
.NH 2
|
|
The load instructions.
|
|
.PP
|
|
In this group a typical instruction is
|
|
.B
|
|
lol
|
|
.R
|
|
.
|
|
A
|
|
.B
|
|
lol
|
|
.R
|
|
instruction pushes the word at local base + offset, where offset
|
|
is the instructions argument, onto the stack.
|
|
Since the MCS6500 can only offset by 256 bytes, as explaned at the
|
|
memory addressing modes, there is a need for two code rules in the
|
|
table.
|
|
One which can offset directly and one that must explicit
|
|
calculate the address of the local.
|
|
.NH 3
|
|
The lol instruction with indirect offsetting.
|
|
.PP
|
|
In this case an indirect offsetted load from the second local base
|
|
is possible.
|
|
The table content is:
|
|
.sp 1
|
|
.br
|
|
.B
|
|
lol
|
|
.R
|
|
IN($1) | |
|
|
.br
|
|
allocate(R16) /* allocate registerpair AX */
|
|
.br
|
|
"ldy #BASE+$1" /* load Y with the offset from the second
|
|
.br
|
|
local base */
|
|
.br
|
|
"lda (LBl),y" /* load indirect the lowbyte of the word */
|
|
.br
|
|
"tax" /* move register A to register X */
|
|
.br
|
|
"iny" /* increment register Y (offset) */
|
|
.br
|
|
"lda (LBl),y" /* load indirect the highbyte of the word */
|
|
.br
|
|
| %[a] | | /* push the word onto the fake stack */
|
|
.NH 3
|
|
The lol instruction whose offset is to big.
|
|
.PP
|
|
In this case, the library subroutine "Lol" is used.
|
|
This subroutine expects the offset in registerpair AX, then
|
|
calculates the address of the local or parameter, and loads
|
|
it into registerpair AX.
|
|
The table content is:
|
|
.sp 1
|
|
.br
|
|
.B
|
|
lol
|
|
.R
|
|
| |
|
|
.br
|
|
allocate(R16) /* allocate registerpair AX */
|
|
.br
|
|
"lda #[$1].h" /* load highbyte of offset into register A */
|
|
.br
|
|
"ldx #[$1].l" /* load lowbyte of offset into register X */
|
|
.br
|
|
"jsr Lol" /* perform the subroutine */
|
|
.br
|
|
| %[a] | | /* push word onto the fake stack */
|
|
.NH 2
|
|
The store instructions.
|
|
.PP
|
|
In this group a typical instruction is
|
|
.B
|
|
stl.
|
|
.R
|
|
A
|
|
.B
|
|
stl
|
|
.R
|
|
instruction poppes a word from the stack and stores it in the word
|
|
at local base + offset, where offset is the instructions argument.
|
|
Here also is the need for two code rules in the table as a result
|
|
of the offset limits.
|
|
.NH 3
|
|
The stl instruction with indirect offsetting.
|
|
.PP
|
|
In this case it an indirect offsetted store from the second local
|
|
base is possible.
|
|
The table content is:
|
|
.sp 1
|
|
.br
|
|
.B
|
|
stl
|
|
.R
|
|
IN($1) | R16 | /* expect registerpair AX on top of the
|
|
.br
|
|
fake stack */
|
|
.br
|
|
"ldy #BASE+1+$1" /* load Y with the offset from the
|
|
.br
|
|
second local base */
|
|
.br
|
|
"sta (LBl),y" /* store the highbyte of the word from A */
|
|
.br
|
|
"txa" /* move register X to register A */
|
|
.br
|
|
"dey" /* decrement offset */
|
|
.br
|
|
"sta (LBl),y" /* store the lowbyte of the word from A */
|
|
.br
|
|
| | |
|
|
.NH 3
|
|
The stl instruction whose offset is to big.
|
|
.PP
|
|
In this case the library subroutine 'Stl' is used.
|
|
This subroutine expects the offset in registerpair AX, then
|
|
calculates the address, poppes the word stores it at its place.
|
|
The table content is:
|
|
.sp 1
|
|
.br
|
|
.B
|
|
stl
|
|
.R
|
|
| |
|
|
.br
|
|
allocate(R16) /* allocate registerpair AX */
|
|
.br
|
|
"lda #[$1].h" /* load highbyte of offset in register A */
|
|
.br
|
|
"ldx #[$1].l" /* load lowbyte of offset in register X */
|
|
.br
|
|
"jsr Stl" /* perform the subroutine */
|
|
.br
|
|
| | |
|
|
.NH 2
|
|
Integer arithmetic instructions.
|
|
.PP
|
|
In this group typical instructions are
|
|
.B
|
|
adi
|
|
.R
|
|
and
|
|
.B
|
|
mli.
|
|
.R
|
|
These instructions, in this table, are implemented for 2-byte
|
|
and 4-byte integers.
|
|
The only arithmetic instructions available on the MCS6500 are
|
|
the ADC (add with carry), and SBC (subtract with not(carry)).
|
|
Not(carry) here means that in a subtraction, the one's complement
|
|
of the carry is taken.
|
|
The absence of multiply and division instructions forces the
|
|
use of subroutines to handle these cases.
|
|
Because there are no registers left to perform on the multiply
|
|
and division, zero page is used here.
|
|
The 4-byte integer arithmetic is implemented, because in C there
|
|
exists the integer type long.
|
|
A user is freely to use the type long, but will pay in performance.
|
|
.NH 3
|
|
The adi instruction.
|
|
.PP
|
|
In case of the
|
|
.B
|
|
adi
|
|
.R
|
|
2 (and
|
|
.B
|
|
sbi
|
|
.R
|
|
2) instruction there are many EM
|
|
patterns, so that the instruction can be performed in line in
|
|
most cases.
|
|
For the worst case there exists a subroutine in the library
|
|
which deals with the EM instruction.
|
|
In case of a
|
|
.B
|
|
adi
|
|
.R
|
|
4 (or
|
|
.B
|
|
sbi
|
|
.R
|
|
4) there only is a subroutine to deal with it.
|
|
A table content is:
|
|
.sp 1
|
|
.br
|
|
.B
|
|
lol lol adi
|
|
.R
|
|
(IN($1) && IN($2) && $3==2) | | /* is it in range */
|
|
.br
|
|
allocate(R16) /* allocate registerpair AX */
|
|
.br
|
|
"ldy #BASE+$1+1" /* load Y with offset for first operand */
|
|
.br
|
|
"lda (LBl),y" /* load indirect highbyte first operand */
|
|
.br
|
|
"pha" /* save highbyte first operand on hard_stack */
|
|
.br
|
|
"dey" /* decrement offset first operand */
|
|
.br
|
|
"lda (LBl),y" /* load indirect lowbyte first operand */
|
|
.br
|
|
"ldy #BASE+$2" /* load Y with offset for second operand */
|
|
.br
|
|
"clc" /* clear carry for addition */
|
|
.br
|
|
"adc (LBl),y" /* add the lowbytes of the operands */
|
|
.br
|
|
"tax" /* store lowbyte of result in place */
|
|
.br
|
|
"iny" /* increment offset second operand */
|
|
.br
|
|
"pla" /* get highbyte first operand */
|
|
.br
|
|
"adc (LBl),y" /* add the highbytes of the operands */
|
|
.br
|
|
| %[a] | | /* push the result onto the fake stack */
|
|
.NH 3
|
|
The mli instruction.
|
|
.PP
|
|
The
|
|
.B
|
|
mli
|
|
.R
|
|
2 instruction uses most the subroutine 'Mlinp'.
|
|
This subroutine expects the multiplicand in zero page
|
|
at locations ARTH, ARTH+1, while the multiplier is in zero
|
|
page locations ARTH+2, ARTH+3.
|
|
For a description of the algorithms used for multiplication and
|
|
division, see [3].
|
|
A table content is:
|
|
.sp 1
|
|
.br
|
|
.B
|
|
lol lol mli
|
|
.R
|
|
(IN($1) && IN($2) && $3==2) | |
|
|
.br
|
|
allocate(R16) /* allocate registerpair AX */
|
|
.br
|
|
"ldy #BASE+$1" /* load Y with offset of multiplicand */
|
|
.br
|
|
"lda (LBl),y" /* load indirect lowbyte of multiplicand */
|
|
.br
|
|
"sta ARTH" /* store lowbyte in zero page */
|
|
.br
|
|
"iny" /* increment offset of multiplicand */
|
|
.br
|
|
"lda (LBl),y" /* load indirect highbyte of multiplicand */
|
|
.br
|
|
"sta ARTH+1" /* store highbyte in zero page */
|
|
.br
|
|
"ldy #BASE+$2" /* load Y with offset of multiplier */
|
|
.br
|
|
"lda (LBl),y" /* load indirect lowbyte of multiplier */
|
|
.br
|
|
"sta ARTH+2" /* store lowbyte in zero page */
|
|
.br
|
|
"iny" /* increment offset of multiplier */
|
|
.br
|
|
"lda (LBl),y" /* load indirect highbyte of multiplier */
|
|
.br
|
|
"sta ARTH+3" /* store highbyte in zero page */
|
|
.br
|
|
"jsr Mlinp" /* perform the multiply */
|
|
.br
|
|
| %[a] | | /* push result onto fake stack */
|
|
.NH 2
|
|
The unsgned arithmetic instructions.
|
|
.PP
|
|
Since unsigned addition an subtraction is performed in the same way
|
|
as signed addition and subtraction, these cases are dealt with by
|
|
an EM replacement.
|
|
For mutiplication and division there are special subroutines.
|
|
.NH 3
|
|
Unsigned addition.
|
|
.PP
|
|
This is an example of the EM replacement strategy.
|
|
.sp 1
|
|
.br
|
|
.B
|
|
lol lol adu
|
|
.R
|
|
| | | |
|
|
.B
|
|
lol
|
|
.R
|
|
$1
|
|
.B
|
|
lol
|
|
.R
|
|
$2
|
|
.B
|
|
adi
|
|
.R
|
|
$3 |
|
|
.NH 2
|
|
Floating point arithmetic.
|
|
.PP
|
|
Floating point arithmetic isn't implemented in this table.
|
|
.NH 2
|
|
Pointer arithmetic instructions.
|
|
.PP
|
|
A typical pointer arithmetic instruction is
|
|
.B
|
|
adp
|
|
.R
|
|
2.
|
|
This instruction adds an offset and a pointer.
|
|
A table content is:
|
|
.sp 1
|
|
.br
|
|
.B
|
|
adp
|
|
.R
|
|
| | | |
|
|
.B
|
|
loc
|
|
.R
|
|
$1
|
|
.B
|
|
adi
|
|
.R
|
|
2 |
|
|
.NH 2
|
|
Increment, decrement and zero instructions.
|
|
.PP
|
|
In this group a typical instruction is
|
|
.B
|
|
inl
|
|
.R
|
|
, which increments a local or parameter.
|
|
The MCS6500 doesn't have an instruction to increment the
|
|
accumulator A, so the 'ADC' instruction must be used.
|
|
A table content is:
|
|
.sp 1
|
|
.br
|
|
.B
|
|
inl
|
|
.R
|
|
IN($1) | |
|
|
.br
|
|
allocate(R16) /* allocate registerpair AX */
|
|
.br
|
|
"ldy #BASE+$1" /* load Y with offset of the local */
|
|
.br
|
|
"clc" /* clear carry for addition */
|
|
.br
|
|
"lda (LBl),y" /* load indirect lowbyte of local */
|
|
.br
|
|
"adc #1" /* increment lowbyte */
|
|
.br
|
|
"sta (LBl),y" /* restore indirect the incremented lowbyte */
|
|
.br
|
|
"bcc 1f" /* if carry is clear then ready */
|
|
.br
|
|
"iny" /* increment offset of local */
|
|
.br
|
|
"lda (LBl),y" /* load indirect highbyte of local */
|
|
.br
|
|
"adc #0" /* add carry to highbyte */
|
|
.br
|
|
"sta (LBl),y\\n1:" /* restore indirect the highbyte */
|
|
.PP
|
|
If the offset of the local or parameter is to big, first the
|
|
local or parameter is fetched, than incremented, and then
|
|
restored.
|
|
.NH 2
|
|
Convert instructions.
|
|
.PP
|
|
In this case there are two convert instructions
|
|
which really do something.
|
|
One of them is in line code, and deals with the extension of
|
|
a character (1-byte) to an integer.
|
|
The other one is a subroutine which handles the conversion
|
|
between 2-byte integers and 4-byte integers.
|
|
.NH 3
|
|
The in line conversion.
|
|
.PP
|
|
The table content is:
|
|
.sp 1
|
|
.br
|
|
.B
|
|
loc loc cii
|
|
.R
|
|
$1==1 && $2==2 | R16 |
|
|
.br
|
|
"txa" /* see if sign extension is needed */
|
|
.br
|
|
"bpl 1f" /* there is no need for sign extension */
|
|
.br
|
|
"lda #0FFh" /* sign extension here */
|
|
.br
|
|
"bne 2f" /* conversion ready */
|
|
.br
|
|
"1: lda #0\\n2:" /* no sign extension here */
|
|
.NH 2
|
|
Logical instructions.
|
|
.PP
|
|
A typical instruction in this group is the logical
|
|
.B
|
|
and
|
|
.R
|
|
on two 2-byte words.
|
|
The logical
|
|
.B
|
|
and
|
|
.R
|
|
on groups of more than two bytes (max 254)
|
|
is also possible and uses a library subroutine.
|
|
.NH 3
|
|
The logical and on 2-byte groups.
|
|
.PP
|
|
The table content is:
|
|
.sp 1
|
|
.br
|
|
.B
|
|
and
|
|
.R
|
|
$1==2 | R16 | /* one group must be on the fake stack */
|
|
.br
|
|
"sta ARTH+1" /* temporary save of first group highbyte */
|
|
.br
|
|
"stx ARTH" /* temporary save of first group lowbyte */
|
|
.br
|
|
"jsr Pop" /* pop second group from the stack */
|
|
.br
|
|
"and ARTH+1" /* logical and on highbytes */
|
|
.br
|
|
"pha" /* temporary save the result's highbyte */
|
|
.br
|
|
"txa" /* logical and can only be done in A */
|
|
.br
|
|
"and ARTH" /* logical and on lowbytes */
|
|
.br
|
|
"tax" /* restore results lowbyte */
|
|
.br
|
|
"pla" /* restore results highbyte */
|
|
.br
|
|
| %[1] | | /* push result onto fake stack */
|
|
.NH 2
|
|
Set manipulation instructions.
|
|
.PP
|
|
A typical EM pattern in this group is
|
|
.B
|
|
loc inn zeq
|
|
.R
|
|
$1>0 && $1<16 && $2==2.
|
|
This EM pattern works on sets of 16 bits.
|
|
Sets can be bigger (max 256 bytes = 2048 bits), but than a
|
|
library routine is used instead of in line code.
|
|
The table content of the above EM pattern is:
|
|
.sp 1
|
|
.br
|
|
.B
|
|
loc inn zeq
|
|
.R
|
|
$1>0 && $1<16 && $2==2 | R16 |
|
|
.br
|
|
"ldy #$1+1" /* load Y with bit number */
|
|
.br
|
|
"stx ARTH" /* cannot rotate X, so use zero page */
|
|
.br
|
|
"1: lsr a" /* right shift A */
|
|
.br
|
|
"ror ARTH" /* right rotate zero page location */
|
|
.br
|
|
"dey" /* decrement Y */
|
|
.br
|
|
"bne 1b" /* shift $1 times */
|
|
.br
|
|
"bcc $1" /* no carry, so bit is zero */
|
|
.NH 2
|
|
Array instructions.
|
|
.PP
|
|
In this group a typical EM pattern is
|
|
.B
|
|
lae lar
|
|
.R
|
|
defined(rom(1,3)) | | | |
|
|
.B
|
|
lae
|
|
.R
|
|
$1
|
|
.B
|
|
aar
|
|
.R
|
|
$2
|
|
.B
|
|
loi
|
|
.R
|
|
rom(1,3).
|
|
This pattern uses the
|
|
.B
|
|
aar
|
|
.R
|
|
instruction, which is part of a typical EM pattern:
|
|
.sp 1
|
|
.br
|
|
.B
|
|
lae aar
|
|
.R
|
|
$2==2 && rom(1,3)==2 && rom(1,1)==0 | R16 | /* registerpair AX contains
|
|
the index in the array */
|
|
.br
|
|
"pha" /* save highbyte of index */
|
|
.br
|
|
"txa" /* move lowbyte of index to A */
|
|
.br
|
|
"asl a" /* shift left lowbyte == 2 times lowbyte */
|
|
.br
|
|
"tax" /* restore lowbyte */
|
|
.br
|
|
"pla" /* restore highbyte */
|
|
.br
|
|
"rol a" /* rotate left highbyte == 2 times highbyte */
|
|
.br
|
|
| %[1] | adi 2 | /* push new index, add to lowerbound array */
|
|
.NH 2
|
|
Compare instructions.
|
|
.PP
|
|
In this group all EM patterns are performed by calling
|
|
a subroutine.
|
|
Subroutines are used here because comparison is only
|
|
possible byte by byte.
|
|
This means a lot of code, and since compare are used frequently
|
|
a lot of in line code would be generated, and thus reducing
|
|
the space left for the software stack.
|
|
These subroutines can be found in the library.
|
|
.NH 2
|
|
Branch instructions.
|
|
.PP
|
|
A typical branch instruction is
|
|
.B
|
|
beq.
|
|
.R
|
|
The table content for it is:
|
|
.sp 1
|
|
.br
|
|
.B
|
|
beq
|
|
.R
|
|
| R16 |
|
|
.br
|
|
"sta BRANCH+1" /* save highbyte second operand in zero page */
|
|
.br
|
|
"stx BRANCH" /* save lowbyte second operand in zero page */
|
|
.br
|
|
"jsr Pop" /* pop the first operand */
|
|
.br
|
|
"cmp BRANCH+1" /* compare the highbytes */
|
|
.br
|
|
"bne 1f" /* there not equal so go on */
|
|
.br
|
|
"cpx BRANCH" /* compare the lowbytes */
|
|
.br
|
|
"beq $1\\n1:" /* lowbytes are also equal, so branch */
|
|
.PP
|
|
Another typical instruction in this group is
|
|
.B
|
|
zeq.
|
|
.R
|
|
The table content is:
|
|
.sp 1
|
|
.br
|
|
.B
|
|
zeq
|
|
.R
|
|
| R16 |
|
|
.br
|
|
"tay" /* move A to Y for setting testbits */
|
|
.br
|
|
"bmi $1" /* highbyte s minus so branch */
|
|
.br
|
|
"txa" /* move X to A for setting testbits */
|
|
.br
|
|
"beq $1\\n1:" /* lowbyte also zero, thus branch */
|
|
.NH 2
|
|
Procedure call instructions.
|
|
.PP
|
|
In this group one code generation might seem a little
|
|
akward.
|
|
It is the EM instruction
|
|
.B
|
|
cai
|
|
.R
|
|
which generates a 'jsr Indir'.
|
|
This is because there is no indirect jump_subroutine in the
|
|
MCS6500.
|
|
The only solution is to store the address in zero page, and then
|
|
do a 'jsr' to a known label.
|
|
At this label there must be an indirect jump instruction, which
|
|
perform a jump to the address stored in zero page.
|
|
In this case the label is Indir, and the address is stored in
|
|
zero page at the addresses ADDR, ADDR+1.
|
|
The tabel content is:
|
|
.sp 1
|
|
.br
|
|
.B
|
|
cai
|
|
.R
|
|
| R16 |
|
|
.br
|
|
"stx ADDR" /* store lowbyte of address in zero page */
|
|
.br
|
|
"sta ADDR+1" /* store highbyte of address in zero page */
|
|
.br
|
|
"jsr Indir" /* use the indirect jump */
|
|
.br
|
|
| | |
|
|
.NH 2
|
|
Miscellaneous instructions.
|
|
.PP
|
|
In this group, as the name suggests, there is no
|
|
typical EM instruction or EM pattern.
|
|
Most of the MCS6500 code to be generated uses a library subroutine
|
|
or is straightforward.
|
|
.DS C
|
|
.B
|
|
PERFORMANCE.
|
|
.R
|
|
.DE
|
|
.NH 0
|
|
Introduction.
|
|
.PP
|
|
To measure the performance of the back end table some timing
|
|
tests are done.
|
|
What to time?
|
|
In this case, the execution time of several Pascal statements
|
|
are timed.
|
|
Statements in C, which have a Pascal equivalence are timed also.
|
|
The statements are timed as follows.
|
|
A test program is been written, which executes two
|
|
nested for_loops from 1 to 1.000.
|
|
Within these for_loops the statement, which is to be tested, is placed,
|
|
so the statement will be executed 1.000.000 times.
|
|
Then the same program is executed without the test statement.
|
|
The time difference between the two executions is the time
|
|
neccesairy to execute the test statement 1.000.000 times.
|
|
The total time to execute the test statement requires thus the
|
|
time difference divided by 1.000.000.
|
|
.NH 0
|
|
Testing Pascal statements.
|
|
.PP
|
|
The next statements are tested.
|
|
.IP 1)
|
|
int1 := 0;
|
|
.IP 2)
|
|
int1 := int2 - 1;
|
|
.IP 3)
|
|
int1 := int1 + 1;
|
|
.IP 4)
|
|
int1 := icon1 - icon2;
|
|
.IP 5)
|
|
int1 := icon2 div icon1;
|
|
.IP 6)
|
|
int1 := int2 * int3;
|
|
.IP 7)
|
|
bool := (int1 < 0);
|
|
.IP 8)
|
|
bool := (int1 < 3);
|
|
.IP 9)
|
|
bool := ((int1 > 3) or (int1 < 3))
|
|
.IP 10)
|
|
case int1 of 1: bool := false; 2: bool := true end;
|
|
.IP 11)
|
|
if int1 = 0 then int2 := 3;
|
|
.IP 12)
|
|
while int1 > 0 do int1 := int1 - 1;
|
|
.IP 13)
|
|
m := a[k];
|
|
.IP 14)
|
|
let2 := ['a'..'c'];
|
|
.IP 15)
|
|
P3(x);
|
|
.IP 16)
|
|
dum := F3(x);
|
|
.IP 17)
|
|
s.overhead := 5400;
|
|
.IP 18)
|
|
with s do overhead := 5400;
|
|
.PP
|
|
These statement were tested in a procedure test.
|
|
.sp 1
|
|
.br
|
|
procedure test;
|
|
.br
|
|
var i, j, ... : integer;
|
|
.br
|
|
bool : boolean;
|
|
.br
|
|
let2 : set of char;
|
|
.br
|
|
begin
|
|
.br
|
|
for i := 1 to 1000
|
|
.br
|
|
for j := 1 to 1000
|
|
.br
|
|
STATEMENT
|
|
.br
|
|
end;
|
|
.sp 1
|
|
.PP
|
|
STATEMENT is one of the statements as shown above, or it is
|
|
the empty statement.
|
|
The assignment of used variables, if neccesairy, is done before
|
|
the first for_loop.
|
|
In case of the statement which uses the procedure call, statement
|
|
15, a dummy procedure is declared whose body is empty.
|
|
In case of the statement which uses the function, statement 16,
|
|
this function returns its argument.
|
|
for the timing of C statements a similar test program was
|
|
written.
|
|
.sp 1
|
|
.br
|
|
main()
|
|
.br
|
|
{
|
|
.br
|
|
int i, j, ...;
|
|
.br
|
|
for (i = 1; i <= 1000; i++)
|
|
.br
|
|
for (j = 1; j <= 1000; j++)
|
|
.br
|
|
STATEMENT
|
|
.br
|
|
}
|
|
.sp 1
|
|
.NH
|
|
The results.
|
|
.PP
|
|
Here are tables with the results of the time measurments.
|
|
Times are in microseconds (10^-6).
|
|
Some statements appear twice in the tables.
|
|
In the second case an array of 200 integers was declerated
|
|
before the variable to be tested, so this variable cannot
|
|
be accessed by indirect addressing from the second local base.
|
|
This results in a larger execution time of the statement to be
|
|
tested.
|
|
The column 68000 contains the times measured on a Bleasdale,
|
|
M68000 based, computer.
|
|
The times in column pdp are measured on a DEC pdp11/44, where
|
|
the times from column 6500 come from a BBC microcomputer.
|
|
.bp
|
|
.TS
|
|
expand;
|
|
c s s s
|
|
c c c c
|
|
lw35 nw7 nw7 nw7.
|
|
Pascal timing results
|
|
statement 68000 pdp 6500
|
|
_
|
|
T{
|
|
int1 := 0;
|
|
T} 4.0 5.8 16.7
|
|
4.0 4.2 97.8
|
|
_
|
|
T{
|
|
int1 := int2 - 1;
|
|
T} 7.2 7.1 27.2
|
|
6.9 7.1 206.5
|
|
_
|
|
T{
|
|
int1 := int1 + 1;
|
|
T} 6.9 6.8 27.2
|
|
6.4 6.7 106.5
|
|
_
|
|
T{
|
|
int1 := icon1 + icon2;
|
|
T} 6.2 6.2 25.6
|
|
6.2 6.0 106.6
|
|
_
|
|
T{
|
|
int1 := icon2 div icon1;
|
|
T} 14.9 14.3 372.6
|
|
14.9 14.7 453.7
|
|
_
|
|
T{
|
|
int1 := int2 * int3;
|
|
T} 11.5 12.0 558.1
|
|
11.3 11.6 728.6
|
|
_
|
|
T{
|
|
bool := (int1 < 0);
|
|
T} 7.2 6.9 122.8
|
|
7.8 8.1 453.2
|
|
_
|
|
T{
|
|
bool := (int1 < 3);
|
|
T} 7.3 7.6 126.0
|
|
7.2 8.1 232.2
|
|
_
|
|
T{
|
|
bool := ((int1 > 3) or (int1 < 3))
|
|
T} 10.1 12.0 307.8
|
|
10.2 11.9 440.1
|
|
_
|
|
T{
|
|
case int1 of 1: bool := false; 2: bool := true end;
|
|
T} 18.3 17.9 165.7
|
|
_
|
|
T{
|
|
if int1 = 0 then int2 := 3;
|
|
T} 9.5 8.5 133.8
|
|
_
|
|
T{
|
|
while int1 > 0 do int1 := int1 - 1;
|
|
T} 6.9 6.9 126.0
|
|
_
|
|
T{
|
|
m := a[k];
|
|
T} 7.2 6.8 134.3
|
|
_
|
|
T{
|
|
let2 := ['a'..'c'];
|
|
T} 38.4 38.8 447.4
|
|
_
|
|
T{
|
|
P3(x);
|
|
T} 18.9 18.8 180.3
|
|
_
|
|
T{
|
|
dum := F3(x);
|
|
T} 26.8 27.1 343.3
|
|
_
|
|
T{
|
|
s.overhead := 5400;
|
|
T} 4.6 4.1 16.7
|
|
_
|
|
T{
|
|
with s do overhead := 5400;
|
|
T} 4.2 4.3 16.7
|
|
.TE
|
|
.TS
|
|
expand;
|
|
c s s s
|
|
c c c c
|
|
lw35 nw7 nw7 nw7.
|
|
C timing results
|
|
statement 68000time pdptime 6500time
|
|
_
|
|
T{
|
|
int1 = 0;
|
|
T} 4.1 3.6 17.2
|
|
4.1 4.1 97.7
|
|
_
|
|
T{
|
|
int1 = int2 - 1;
|
|
T} 6.6 6.9 27.2
|
|
6.1 6.5 206.4
|
|
_
|
|
T{
|
|
int1 = int1 + 1;
|
|
T} 6.4 7.3 27.2
|
|
6.3 6.2 206.4
|
|
_
|
|
T{
|
|
int1 = int2 * int3;
|
|
T} 11.4 12.3 522.6
|
|
9.6 10.1 721.2
|
|
_
|
|
T{
|
|
int1 = (int2 < 0);
|
|
T} 7.2 7.6 126.4
|
|
7.4 7.7 232.5
|
|
_
|
|
T{
|
|
int1 = (int2 < 3);
|
|
T} 7.0 7.5 126.0
|
|
7.8 7.8 232.6
|
|
_
|
|
T{
|
|
int1 = ((int2 > 3) || (int2 < 3));
|
|
T} 11.8 12.2 193.4
|
|
11.5 13.2 245.6
|
|
_
|
|
T{
|
|
switch (int1) { case 1: int1 = 0; break; case 2: int1 = 1; break; }
|
|
T} 28.3 29.2 164.1
|
|
_
|
|
T{
|
|
if (int1 == 0) int2 = 3;
|
|
T} 4.8 4.8 19.4
|
|
_
|
|
T{
|
|
while (int2 > 0) int2 = int2 - 1;
|
|
T} 5.8 6.0 125.9
|
|
_
|
|
T{
|
|
int2 = a[int2];
|
|
T} 4.8 5.1 192.8
|
|
_
|
|
T{
|
|
P3(int2);
|
|
T} 18.8 18.4 180.3
|
|
_
|
|
T{
|
|
int2 = F3(int2);
|
|
T} 27.0 27.2 309.4
|
|
_
|
|
T{
|
|
s.overhead = 5400;
|
|
T} 5.0 4.1 16.7
|
|
.TE
|
|
.NH
|
|
Pascal statements which don't have a C equivalent.
|
|
.PP
|
|
At first, the two statements who perform an operation on constants
|
|
are left out.
|
|
These are left out while the C front end does constant folding,
|
|
while the Pascal front end doesn't.
|
|
So in C the statements int1 = icon1 + icon2; and int1 = icon1 / icont2;
|
|
will use the same amount of time since the expression is evaluated
|
|
by the front end.
|
|
The two other statements (let2 := ['a'..'c']; and
|
|
.B
|
|
with
|
|
.R
|
|
s
|
|
.B
|
|
do
|
|
.R
|
|
overhead := 5400;), aren't included in the C statement timing table,
|
|
because there constructs do not exist in C.
|
|
Although in C there can be direct bit manipulation, and thus can
|
|
be used to implement sets I have not used it here.
|
|
The
|
|
.B
|
|
with
|
|
.R
|
|
statement does not exists in C and there is nothing with the slightest
|
|
resemblance to it.
|
|
.PP
|
|
At first sight in the table , it looked if there is no much difference
|
|
in the times for the M68000 and the pdp11/44, in comparison with the
|
|
times needed by the MCS6500.
|
|
To verify this impression, I calculated the correlation coefficient
|
|
between the times of the M68000 and pdp11/44.
|
|
It turned out to be 0.997 for both the Pascal time tests and the C
|
|
time tests.
|
|
Since the correlation coefficient is near to one and the difference
|
|
between the times is small, they can be considered to be the same
|
|
as seen from the times of the MCS6500.
|
|
Then I have tried to make a grafic of the times from the M68000 and
|
|
the MCS6500.
|
|
Well, there was't any correlation to been seen, taken all the times.
|
|
The only correlation one could see, with some effort, was in the
|
|
times for the first three Pascal statements.
|
|
The two first C statements show also a correlation, which two points
|
|
always do.
|
|
.PP
|
|
Also the three Pascal statements
|
|
.B
|
|
case
|
|
.R
|
|
,
|
|
.B
|
|
if
|
|
.R
|
|
,
|
|
and
|
|
.B
|
|
while
|
|
.R
|
|
have a correlation coefficient of 0.999.
|
|
This is probably because the
|
|
.B
|
|
case
|
|
.R
|
|
statement uses a subroutine in both cases and the other two
|
|
statements
|
|
.B
|
|
if
|
|
.R
|
|
and,
|
|
.B
|
|
while
|
|
.R
|
|
generate in line code.
|
|
The last two Pascal statements use the same time, since the front
|
|
end wil generate the same EM code for both.
|
|
.PP
|
|
The independence between the rest of the test times is because
|
|
in these cases the object code for the MCS6500 uses library
|
|
subroutines, while the other processors can handle the EM code
|
|
with in line code.
|
|
.PP
|
|
It is clear that the MCS6500 is a slower device, it needs longer
|
|
execution times, the need of more library subroutines, but
|
|
there is no constant factor between it execution times and those
|
|
of other processors.
|
|
.PP
|
|
The slowing down of the MCS6500 as result of the need of a
|
|
library subroutine is illustrated by the muliplication
|
|
statement.
|
|
The MCS6500 needs a library subroutine, while the other
|
|
two processors have a machine instruction to perform the
|
|
multiply.
|
|
This results in a factor of 48.5, when the operands can be accessed
|
|
indirect by the MCS6500.
|
|
When the MCS6500 cannot access the operands indirectly the situation
|
|
is even worse.
|
|
The slight differences between the MCS6500 execution times for
|
|
Pascal statements and C statements is probably the result of the
|
|
front end, and thus beyond the scope of this discussion.
|
|
.PP
|
|
Another timing test is done in C on the statement k = i + j + 1983.
|
|
This statement is tested on many UNIX*
|
|
.FS
|
|
* UNIX is a Trademark of Bell Laboratories.
|
|
.FE
|
|
systems.
|
|
For a complete list see appendix A.
|
|
The slowest one is the IBM XT, which runs on a 8088 microprocessor.
|
|
The fasted one is the Amdahl computer.
|
|
Here is short table to illustrate the performance of the
|
|
MCS6500.
|
|
.TS
|
|
c c c
|
|
c n n.
|
|
machine short int
|
|
IBM XT 53.4 53.4
|
|
Amdahl 0.5 0.3
|
|
MCS6500 150.2 150.2
|
|
.TE
|
|
The MCS6500 is three times slower than the IBM XT, but threehundred
|
|
times slower than the Amdahl.
|
|
The reason why the times on the IBM XT and the MCS6500 are the
|
|
same for short's and int's, is that most C compilers make the types
|
|
short and integer the same size on 16-bit machines.
|
|
In this project the MCS6500 is regarded as a 16-bit machine.
|
|
.NH
|
|
Length tests.
|
|
.PP
|
|
I have also compiled several programs written in Pascal and C to
|
|
see if there is a resemblance between the number of bytes generated
|
|
in the machine's language.
|
|
In the tables:
|
|
.IP length: 9
|
|
The number of bytes of the source program.
|
|
.IP 68000:
|
|
The number of bytes of the a.out file for a M68000.
|
|
.IP pdp:
|
|
The number of bytes of the a.out file for a pdp11/44.
|
|
.IP 6500:
|
|
The number of bytes of the a.out file for a MCS6500.
|
|
.LP
|
|
These are the results:
|
|
.TS
|
|
c s s s
|
|
c c c c
|
|
n n n n.
|
|
Pascal programs
|
|
length 68000 pdp 6500
|
|
_
|
|
19946 14383 16090 26710
|
|
19484 20169 20190 35416
|
|
10849 10469 11464 18949
|
|
273 4221 5106 7944
|
|
1854 5807 6610 10301
|
|
.TE
|
|
.TS
|
|
c s s s
|
|
c c c c
|
|
n n n n.
|
|
C progams
|
|
length 68000 pdp 6500
|
|
_
|
|
9444 6927 8234 11559
|
|
7655 14353 18240 26251
|
|
4775 11309 15934 19910
|
|
639 6337 9660 12494
|
|
.TE
|
|
.PP
|
|
In contrast to the execution times of the test statements, the
|
|
object code files sizes show a constant factor between them.
|
|
After calculating the correlation coefficient, I have calculated
|
|
the line fitted between sizes.
|
|
.FS
|
|
* x is the number of bytes
|
|
.FE
|
|
.TS
|
|
c s s
|
|
c c c
|
|
l c c.
|
|
Pascal programs
|
|
processor corr. coef. fitted line
|
|
_
|
|
68000-pdp 0.996
|
|
68000-6500 0.999 1.76x + 502*
|
|
pdp-6500 0.999 1.80x - 1577
|
|
.TE
|
|
.TS
|
|
c s s
|
|
c c c
|
|
l c c.
|
|
C programs
|
|
processor corr. coef. fitted line
|
|
_
|
|
68000-pdp 0.974
|
|
68000-6500 0.992 1.80x + 502*
|
|
pdp-6500 0.980 1.40x - 1577
|
|
.TE
|
|
.PP
|
|
As seen from the tables above the correlation coefficient for
|
|
Pascal programs is better than the ones for C programs.
|
|
Thus the line fits best for Pascal programs.
|
|
With the formula of the best fitted line one can now estimate
|
|
the size of the object code, which a program needs, for a MCS6500
|
|
without having the compiler at hand.
|
|
One also can see from these formula that the object code
|
|
generated for a MCS6500 is about 1.8 times more than for the other
|
|
processors.
|
|
Since the number of bytes in the source file havily depends on the
|
|
programmer, how many spaces he or she uses, the size of the indenting
|
|
in structured programs, etc., there is no correlation between the
|
|
size of the source file and the size of the object file.
|
|
Also the use of comments has its influence on the size.
|
|
.bp
|
|
.DS C
|
|
.B
|
|
SUMMARY.
|
|
.R
|
|
.DE
|
|
.NH 0
|
|
Summary
|
|
.PP
|
|
In this chapter some final conclusions are made.
|
|
.PP
|
|
In spite of its simplicity, the MCS6500 is strong enough to
|
|
implement a EM machine.
|
|
A serious deficy of the MCS6500 is the missing of 16-bit
|
|
general purpose registers, and especially the missing of a
|
|
16-bit stackpointer.
|
|
As pointed out before, one 16-bit register can be simulated
|
|
by a pair of 8-bit registers, in fact, the accumulator A to
|
|
hold the highbyte, and the index register X to hold the lowbyte
|
|
of the word.
|
|
By lack of a 16-bit stackpointer, zero page must be used to hold
|
|
a stackpointer and there are also two subroutines needed for
|
|
manipulating the stack (Push and Pop).
|
|
.PP
|
|
As seen at the time tests, the simple instruction set of the
|
|
MCS6500 forces the use of library subroutines.
|
|
These library subroutines increas the execution time of the
|
|
programs.
|
|
.PP
|
|
The sizes of the object code files show a strong correlation
|
|
in contrast to the execution times.
|
|
With this correlatiuon one canestimate the size of a program
|
|
if it is to be used on a MCS6500.
|
|
.bp
|
|
.NH 0
|
|
.B
|
|
REFERENCES.
|
|
.R
|
|
.IP 1.
|
|
Osborn, A., Jacobson, S., and Kane, J. The Mos Technology MCS6500.
|
|
.B
|
|
An Introduction to Microcomputers ,
|
|
.R
|
|
Volume II, Some Real Products (june 1977) chap. 9.
|
|
.RS
|
|
.PP
|
|
A hardware description of some real existing CPU's, such as
|
|
the Intel Z80, MCS6500, etc. is given in this book.
|
|
.RE
|
|
.IP 2.
|
|
van Staveren, H.
|
|
The table driven code generator from the Amsterdam Compiler Kit.
|
|
Vrije Universiteit, Amsterdam, (July 11, 1983).
|
|
.RS
|
|
.PP
|
|
The defining document for writing a back end table.
|
|
.RE
|
|
.IP 3.
|
|
Tanenbaum, A.S. Structured Computer Organization.
|
|
Prentice Hall. (1976).
|
|
.RS
|
|
.PP
|
|
In this book computers are described as a hierarchy of levels,
|
|
with each one performing some well-defined function.
|
|
.RE
|