123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853854855856857858859860861862863864865866867868869870871872873874875876877878879880881882883884885886887888889890891892893894895896897898899900901902903904905906907908909910911912913914915916917918919920921922923924925926927928929930931932933934935936937938939940941942943944945946947948949950951952953954955956957958959960961962963964965966967968969970971972973974975976977978979980981982983984985986987988989990991992993994995996997998999100010011002100310041005100610071008100910101011101210131014101510161017101810191020102110221023102410251026102710281029103010311032103310341035103610371038103910401041104210431044104510461047104810491050105110521053105410551056105710581059106010611062106310641065106610671068106910701071107210731074107510761077107810791080108110821083108410851086108710881089109010911092109310941095109610971098109911001101110211031104110511061107110811091110111111121113111411151116111711181119112011211122112311241125112611271128112911301131113211331134113511361137113811391140114111421143114411451146114711481149115011511152115311541155115611571158115911601161116211631164116511661167116811691170117111721173117411751176117711781179118011811182118311841185118611871188118911901191119211931194119511961197119811991200120112021203120412051206120712081209121012111212121312141215121612171218121912201221122212231224122512261227122812291230123112321233123412351236123712381239124012411242124312441245124612471248124912501251125212531254125512561257125812591260126112621263126412651266126712681269127012711272127312741275127612771278127912801281128212831284128512861287128812891290129112921293129412951296129712981299130013011302130313041305130613071308130913101311131213131314131513161317131813191320132113221323132413251326132713281329133013311332133313341335133613371338133913401341134213431344134513461347134813491350135113521353135413551356135713581359136013611362136313641365136613671368136913701371137213731374137513761377137813791380138113821383138413851386138713881389139013911392139313941395139613971398139914001401140214031404140514061407140814091410141114121413141414151416141714181419142014211422142314241425142614271428142914301431143214331434143514361437143814391440144114421443144414451446144714481449145014511452145314541455145614571458145914601461146214631464146514661467146814691470147114721473147414751476147714781479148014811482148314841485148614871488148914901491149214931494149514961497149814991500150115021503150415051506150715081509151015111512151315141515151615171518151915201521152215231524152515261527152815291530153115321533153415351536153715381539154015411542154315441545154615471548154915501551155215531554155515561557155815591560156115621563156415651566156715681569157015711572157315741575157615771578157915801581158215831584158515861587158815891590159115921593159415951596159715981599160016011602160316041605160616071608160916101611161216131614161516161617161816191620162116221623162416251626162716281629163016311632163316341635163616371638163916401641164216431644164516461647164816491650165116521653165416551656165716581659166016611662166316641665166616671668166916701671167216731674167516761677167816791680168116821683168416851686168716881689169016911692169316941695169616971698169917001701170217031704170517061707170817091710171117121713171417151716171717181719172017211722172317241725172617271728172917301731173217331734173517361737173817391740174117421743174417451746174717481749175017511752175317541755175617571758175917601761176217631764176517661767176817691770177117721773177417751776177717781779178017811782178317841785178617871788178917901791179217931794179517961797179817991800180118021803180418051806180718081809181018111812181318141815181618171818181918201821182218231824182518261827182818291830183118321833183418351836183718381839184018411842184318441845184618471848184918501851185218531854185518561857185818591860186118621863186418651866186718681869187018711872187318741875187618771878187918801881188218831884188518861887188818891890189118921893 |
- . \" $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
|