i80.doc 28 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830
  1. ." $Header$
  2. .RP
  3. .TL
  4. Back end table for the Intel 8080 micro-processor
  5. .AU
  6. Gerard Buskermolen
  7. .AB
  8. A back end is a part of the Amsterdam Compiler Kit (ACK).
  9. It translates EM, a family of intermediate languages, into the
  10. assembly language of some target machine, here the Intel 8080 and Intel 8085 microprocessors.
  11. .AE
  12. .NH1
  13. INTRODUCTION
  14. .PP
  15. To simplify the task of producing portable (cross) compilers and
  16. interpreters, the Vrije Universiteit designed an integrated collection
  17. of programs, the Amsterdam Compiler Kit (ACK).
  18. It is based on the old UNCOL-idea ([4]) which attempts to solve the problem
  19. of making a compiler for each of
  20. .B N
  21. languages on
  22. .B M
  23. different machines without having to write
  24. .B N\ *\ M
  25. programs.
  26. .sp 1
  27. The UNCOL approach is to write
  28. .B N
  29. "front ends", each of which translates one source language into
  30. a common intermediate language, UNCOL (UNiversal Computer Oriented
  31. Language), and
  32. .B M
  33. "back ends", each of which translates programs in UNCOL into a
  34. specific machine language.
  35. Under these conditions, only
  36. .B N\ +\ M
  37. programs should be written to provide all
  38. .B N
  39. languages on all
  40. .B M
  41. machines, instead of
  42. .B N\ *\ M
  43. programs.
  44. .sp 1
  45. The intermediate language for the Amsterdam Compiler Kit is the machine
  46. language for a simple stack machine called EM (Encoding Machine).
  47. So a back end for the Intel 8080 micro translates EM code into
  48. 8080 assembly language.
  49. .sp 1
  50. The back end is a single program that is driven by a machine dependent
  51. driving table.
  52. This driving table, or back end table,
  53. defines the mapping from EM code to the machine's assembly language.
  54. .NH 1
  55. THE 8080 MICRO PROCESSOR
  56. .PP
  57. This back end table can be used without modification for the Intel 8085
  58. processor.
  59. Except for two additional instructions, the 8085 instruction set
  60. is identical and fully compatible with the 8080 instruction set.
  61. So everywhere in this document '8080' can be read as '8080 and 8085'.
  62. .NH 2
  63. Registers
  64. .PP
  65. The 8080 processor has an 8 bit accumulator,
  66. six general purpose 8-bit registers,
  67. a 16 bit programcounter and a 16 bit stackpointer.
  68. Assembler programs can refer the accumulator by A and
  69. the general purpose registers by B, C, D, E, H and L. (*)
  70. .FS
  71. * In this document 8080 registers and mnemonics are referenced by capitals, for the sake of clarity.
  72. Nevertheless the assembler expects small letters.
  73. .FE
  74. Several instructions address registers in groups of two, thus creating
  75. 16 bit registers:
  76. .DS
  77. Registers referenced: Symbolic reference:
  78. B and C B
  79. D and E D
  80. H and L H
  81. .DE
  82. The first named register, contains the high order byte
  83. (H and L stand for High and Low).
  84. .br
  85. The instruction determines how the processor interprets the reference.
  86. For example, ADD B is an 8 bit operation, adding the contents of
  87. register B to accumulator A. By contrast PUSH B is a 16 bit operation
  88. pushing B and C onto the stack.
  89. .sp 1
  90. There are no index registers.
  91. .sp 1
  92. .NH 2
  93. Flip-flops
  94. .PP
  95. The 8080 microprocessor provides five flip-flops used as condition flags
  96. (S, Z, P, C, AC) and one interrupt enable flip-flop IE.
  97. .br
  98. The sign bit S is set (cleared) by certain instructions when the most significant
  99. bit of the result of an operation equals one (zero).
  100. .br
  101. The zero bit Z is set (cleared) by certain operations when the
  102. 8-bit result of an operation equals (does not equal) zero.
  103. .br
  104. The parity bit P is set (cleared) if the 8-bit result of an
  105. operation includes an even (odd) number of ones.
  106. .br
  107. C is the normal carry bit.
  108. .br
  109. AC is an auxiliary carry that indicates whether there has been a carry
  110. out of bit 3 of the accumulator.
  111. This auxiliary carry is used only by the DAA instruction, which
  112. adjusts the 8-bit value in the accumulator to form two 4-bit
  113. binary coded decimal digits.
  114. Needless to say this instruction is not used in the back-end.
  115. .sp 1
  116. The interrupt enable flip-flop IE is set and cleared under
  117. program control using the instructions EI (Enable Interrupt) and
  118. DI (Disable Interrupt).
  119. It is automatically cleared when the CPU is reset and when
  120. an interrupt occurs, disabling further interrupts until IE = 1 again.
  121. .NH 2
  122. Addressing modes
  123. .NH 3
  124. Implied addressing
  125. .PP
  126. The addressing mode of some instructions is implied by the instruction itself.
  127. For example, the RAL (rotate accumulator left) instruction deals only with
  128. the accumulator, and PCHL loads the programcounter with the contents
  129. of register-pair HL.
  130. .NH 3
  131. Register addressing
  132. .PP
  133. With each intruction using register addressing,
  134. only one register is specified (except for the MOV instruction),
  135. although in many of them the accumulator is implied as
  136. second operand.
  137. Examples are CMP E, which compares register E with the accumulator,
  138. and DCR B, which decrements register B.
  139. .br
  140. A few instructions deal with 16 bit register-pairs:
  141. examples are DCX B, which decrements register-pair BC and the
  142. PUSH and POP instructions.
  143. .NH 3
  144. Register indirect addressing
  145. .PP
  146. Each instruction that may refer to an 8 bit register, may
  147. refer also to a memory location. In this case the letter M
  148. (for Memory) has to be used instead of a register.
  149. It indicates the memory location pointed to by H and L,
  150. so ADD M adds the contents of the memory location specified
  151. by H and L to the contents of the accumulator.
  152. .br
  153. The register-pairs BC and DE can also be used for indirect addressing,
  154. but only to load or store the accumulator.
  155. For example, STAX B stores the contents of the accumulator
  156. into the memory location addressed by register-pair BC.
  157. .NH 3
  158. Immediate addressing
  159. .PP
  160. The immediate value can be an 8 bit value, as in ADI 10 which
  161. adds 10 to the accumulator, or a 16 bit value, as in
  162. LXI H,1000, which loads 1000 in the register-pair HL.
  163. .NH 3
  164. Direct addressing
  165. .PP
  166. Jump instructions include a 16 bit address as part of the instruction.
  167. .br
  168. The instruction SHLD 1234 stores the contents of register
  169. pair HL on memory locations 1234 and 1235.
  170. The high order byte is stored at the highest address.
  171. .NH 1
  172. THE 8080 BACK END TABLE
  173. .PP
  174. The back end table is designed as described in [5].
  175. So for an overall design of a back end table I refer to this document.
  176. .br
  177. This section deals with problems encountered in writing the
  178. 8080 back-end table.
  179. Some remarks are made about particular parts
  180. of the table that might not seem clear at first sight.
  181. .NH 2
  182. Constant definitions
  183. .PP
  184. Word size (EM_WSIZE) and pointer size (EM_PSIZE) are both
  185. defined as two bytes.
  186. The hole between AB and LB (EM_BSIZE) is four bytes: only the
  187. return address and the localbase are saved.
  188. .NH 2
  189. Registers and their properties
  190. .PP
  191. All properties have the default size of two bytes, because one-byte
  192. registers also cover two bytes when put on the real stack.
  193. .sp 1
  194. The next considerations led to the choise of register-pair BC
  195. as localbase.
  196. Though saving the localbase in memory would leave one more register-pair
  197. available as scratch register, it would slow down instructions
  198. as 'lol' and 'stl' too much.
  199. So a register-pair should be sacrificed as localbase.
  200. Because a back-end without a free register-pair HL is completely
  201. broken-winged, the only reasonable choises are BC and DE.
  202. Though the choise between them might seem arbitrary at first sight,
  203. there is a difference between register-pairs BC and DE:
  204. the instruction XCHG exchanges the contents of register-pairs DE and
  205. HL.
  206. When DE and HL are both heavily used on the fake-stack, this instruction
  207. is very usefull.
  208. Since it won't be usefull too often to exchange HL with the localbase
  209. and since an instruction exchanging BC and HL does not exist, BC is
  210. chosen as localbase.
  211. .sp 1
  212. Many of the register properties are never mentioned in the
  213. PATTERNS part of the table.
  214. They are only needed to define the INSTRUCTIONS correctly.
  215. .sp 1
  216. The properties really used in the PATTERNS part are:
  217. .IP areg: 24
  218. the accumulator only
  219. .IP reg:
  220. any of the registers A, D, E, H or L. Of course the registers B and C which are
  221. used as localbase don't possess this property.
  222. When there is a single register on the fake-stack, its value
  223. is always considered non-negative.
  224. .IP dereg:
  225. register-pair DE only
  226. .IP hlreg:
  227. register-pair HL only
  228. .IP hl_or_de:
  229. register-pairs HL and DE both have this property
  230. .IP localbase:
  231. used only once (i.e. in the EM-instruction 'str 0')
  232. .PP
  233. .sp 1
  234. The stackpointer SP and the processor status word PSW have to be
  235. defined explicitely because they are needed in some instructions
  236. (i.e. SP in LXI, DCX and INX and PSW in PUSH and POP).
  237. .br
  238. It doesn't matter that the processor status word is not just register A
  239. but includes the condition flags.
  240. .NH 2
  241. Tokens
  242. .PP
  243. The tokens 'm' and 'const1' are used in the INSTRUCTIONS- and MOVES parts only.
  244. They will never be on the fake-stack.
  245. .sp 1
  246. The token 'label' reflects addresses known at assembly time.
  247. It is used to take full profit of the instructions LHLD
  248. (Load HL Direct) and SHLD (Store HL Direct).
  249. .sp 1
  250. Compared with many other back-end tables, there are only a small number of
  251. different tokens (four).
  252. Reasons are the limited addressing modes of the 8080 microprocessor,
  253. no index registers etc.
  254. .br
  255. For example to translate the EM-instruction
  256. .DS
  257. lol 10
  258. .DE
  259. the next 8080 instructions are generated:
  260. .DS L
  261. LXI H,10 /* load registers pair HL with value 10 */
  262. DAD B /* add localbase (BC) to HL */
  263. MOV E,M /* load E with byte pointed to by HL */
  264. INX H /* increment HL */
  265. MOV D,M /* load D with next byte */
  266. .DE
  267. Of course, instead of emitting code immmediately, it could be postponed
  268. by placing something like a {LOCAL,10} on the fake-stack, but some day the above
  269. mentioned code will have to be generated, so a LOCAL-token is
  270. hardly usefull.
  271. .br
  272. See also the comment on the load instructions.
  273. .NH 2
  274. Sets
  275. .PP
  276. Only 'src1or2' is used in the PATTERNS.
  277. .NH 2
  278. Instructions
  279. .PP
  280. Each instruction indicates whether or not the condition flags
  281. are affected, but this information will never have any influence
  282. because there are no tests in the PATTERNS part of the table.
  283. .sp 1
  284. For each instruction a cost vector indicates the number of bytes
  285. the instruction occupies and the number of time periods it takes
  286. to execute the instruction.
  287. The length of a time period depends on the clock frequency
  288. and may range from 480 nanoseconds to 2 microseconds on a
  289. 8080 system and from 320 nanoseconds to 2 microseconds
  290. on a 8085 system.
  291. .sp 1
  292. In the TOKENS-part the cost of token 'm' is defined as (0,3).
  293. In fact it usually takes 3 extra time periods when this register indirect mode
  294. is used instead of register mode, but since the costs are not completely
  295. orthogonal this results in small deficiencies for the DCR, INR and MOV
  296. instructions.
  297. Although it is not particularly usefull these deficiencies are
  298. corrected in the INSTRUCTIONS part, by treating the register indirect
  299. mode seperately.
  300. .sp 1
  301. The costs of the conditional call and return instructions really
  302. depend on whether or not the call resp. return is actually made.
  303. Unimportant.
  304. .sp 1
  305. Instructions not used in this table have been commented out.
  306. Of course many of them are used in the library routines.
  307. .NH 2
  308. Moves
  309. .PP
  310. This section is supposed to be straight-forward.
  311. .NH 2
  312. Tests
  313. .PP
  314. The TESTS section is only included to refrain
  315. .B cgg
  316. from complaining.
  317. .NH 2
  318. Stackingrules
  319. .PP
  320. When, for example, the token {const2,10} has to be stacked while
  321. no free register-pair is available, the next code is generated:
  322. .DS
  323. PUSH H
  324. LXI H,10
  325. XTHL
  326. .DE
  327. The last instruction exchanges the contents of HL with the value
  328. on top of the stack, giving HL its original value again.
  329. .NH 2
  330. Coercions
  331. .PP
  332. The coercion to unstack register A, is somewhat tricky,
  333. but unfortunately just popping PSW leaves the high-order byte in
  334. the accumulator.
  335. .sp 1
  336. The cheapest way to coerce HL to DE (or DE to HL) is by using
  337. the XCHG instruction, but it is not possible to explain
  338. .B cgg
  339. this instruction in fact exchanges the contents of these
  340. register-pairs.
  341. Before the coercion is carried out other appearances of DE and HL
  342. on the fake-stack will be moved to the real stack, because in
  343. the INSTRUCTION-part is told that XCHG destroyes the contents
  344. of both DE and HL.
  345. .br
  346. The coercion transposing one register-pair to another one by
  347. emitting two MOV-instructions, will be used only if
  348. one of the register-pairs is the localbase.
  349. .NH 2
  350. Patterns
  351. .PP
  352. As a general habit I have allocated (uses ...) all registers
  353. that should be free to generate the code, although it is not
  354. always necessary.
  355. For example in the code rule
  356. .DS
  357. pat loe
  358. uses hlreg
  359. gen lhld {label,$1} yields hl
  360. .DE
  361. the 'uses'-clause could have been omitted because
  362. .B cgg
  363. knows that LHLD destroyes register-pair HL.
  364. .sp 1
  365. Since there is only one register with property 'hlreg',
  366. there is no difference between 'uses hlreg' (allocate a
  367. register with property 'hlreg') and 'kills hlreg' (remove
  368. all registers with property 'hlreg' from the fake-stack).
  369. The same applies for the property 'dereg'.
  370. .br
  371. As a consequence 'kills' is rarely used in this back-end table.
  372. .NH 3
  373. Group 1: Load instructions
  374. .PP
  375. When a local variable must be squared, there will probably be EM-code like:
  376. .DS
  377. lol 10
  378. lol 10
  379. mli 2
  380. .DE
  381. When the code for the first 'lol 10' has been executed, DE contains the
  382. wanted value.
  383. To refrain
  384. .B cgg
  385. from emitting the code for 'lol 10' again, an extra
  386. pattern is included in the table for cases like this.
  387. .br
  388. The same applies for two consecutive 'loe'-s or 'lil'-s.
  389. .sp 1
  390. A bit tricky is 'lof'.
  391. It expects either DE or HL on the fake-stack, moves {const2,$1}
  392. into the other one, and eventually adds them.
  393. The 'kills' part is necessary here because if DE was on the fake-stack,
  394. .B cgg
  395. doesn't see that the contents of DE is destroyed by the code
  396. (in fact 'kills dereg' would have been sufficient: because of the
  397. DAD instruction
  398. .B cgg
  399. knows that HL is destroyed).
  400. .sp 1
  401. By lookahead,
  402. .B cgg
  403. can make a clever choise between the first and
  404. second code rule of 'loi 4'.
  405. The same applies for several other instructions.
  406. .NH 3
  407. Group 2: Store instructions
  408. .PP
  409. A similar idea as with the two consecutive identical load instructions
  410. in Group 1, applies for a store instruction followed by a corresponding load instruction.
  411. .NH 3
  412. Groups 3 and 4: Signed and unsigned integer arithmetic
  413. .PP
  414. Since the 8080 instruction set doesn't provide multiply and
  415. divide instructions, special routines are made to accomplish these tasks.
  416. .sp 1
  417. Instead of providing four slighty differing routines for 16 bit signed or
  418. unsigned division, yielding the quotient or the remainder,
  419. the routines are merged.
  420. This saves space and assembly time
  421. when several variants are used in a particular program,
  422. at the cost of a little speed.
  423. .br
  424. When the routine is called, bit 7 of register A indicates whether
  425. the operands should be considered as signed or as unsigned integers,
  426. and bit 0 of register A indicates whether the quotient or the
  427. remainder has to be delivered.
  428. .br
  429. The same applies for 32 bit division.
  430. .sp 1
  431. The routine doing the 16 bit unsigned multiplication could
  432. have been used for 16 bit signed multiplication too.
  433. Nevertheless a special 16 bit signed multiplication routine is
  434. provided, because this one will usually be much faster.
  435. .NH 3
  436. Group 5: Floating point arithmetic
  437. .PP
  438. Floating points are not implemented.
  439. .br
  440. Whenever an EM-instruction involving floating points is offered
  441. to the code-generator, it generates the code 'call eunimpl',
  442. which traps with trap number 63.
  443. Some of the Pascal and C library routines output floating point
  444. EM-instructions, so code has to be generated for them.
  445. Of course this doesn't imply the code will ever be executed.
  446. .NH 3
  447. Group 12: Compare instructions
  448. .PP
  449. The code for 'cmu 2', with its 4 labels, is terrible.
  450. But it is the best I could find.
  451. .NH 3
  452. Group 9: Logical instructions
  453. .PP
  454. I have tried to merge both variants of the instructions 'and 2', 'ior 2' and 'xor 2',
  455. as in
  456. .DS
  457. pat and $1==2
  458. with hl_or_de hl_or_de
  459. uses reusing %1, reusing %2, hl_or_de, areg
  460. gen mov a,%1.2
  461. ana %2.2
  462. mov %a.2,a
  463. mov a,%1.1
  464. ana %2.1
  465. mov %a.1,a yields %a
  466. .DE
  467. but the current version of
  468. .B cgg
  469. doesn't approve this.
  470. .br
  471. In any case
  472. .B cgg
  473. chooses either DE or HL to store the result, using lookahead.
  474. .NH 3
  475. Group 14: Procedure call instructions
  476. .PP
  477. There is an 8 bytes function return area, called '.fra'.
  478. If only 2 bytes have to be returned, register-pair DE is used.
  479. .NH 1
  480. LIBRARY ROUTINES
  481. .PP
  482. Most of the library routines start with saving the return address
  483. and the localbase, so that the parameters are on the top of the stack
  484. and the registers B and C are available as scratch registers.
  485. Since register-pair HL is needed to accomplish these tasks,
  486. and also to restore everything just before the routine returns,
  487. it is not possible to transfer data between the routines and the
  488. surrounding world through register H or L.
  489. Only registers A, D and E can be used for this.
  490. .sp
  491. When a routine returns 2 bytes, they are usually returned in
  492. registers-pair DE.
  493. When it returns more than 2 bytes they are pushed onto the stack.
  494. .br
  495. It would have been possible to let the 32 bit arithmetic routines
  496. return 2 bytes in DE and the remaining 2 bytes on the stack
  497. (this often would have saved some space and execution time),
  498. but I don't consider that as well-structured programming.
  499. .NH 1
  500. TRAPS
  501. .PP
  502. Whenever a trap, for example trying to divide by zero,
  503. occurs in a program that originally was written in C or Pascal,
  504. a special trap handler is called.
  505. .br
  506. This trap handler wants to write an appropriate error message on the
  507. monitor.
  508. It tries to read the message from a file (e.g. etc/pc_rt_errors in the
  509. EM home directory for Pascal programs), but since the 8080 back-end
  510. doesn't know about files, we are in trouble.
  511. This problem is solved, as far as possible, by including the 'open'-monitor call in the mon-routine.
  512. It returns with file descriptor -1.
  513. The trap handler reacts by generating another trap, with the original
  514. trap number.
  515. But this time, instead of calling the C- or Pascal trap handler again,
  516. the next message is printed on the monitor:
  517. .DS L
  518. trap number <TN>
  519. line <LN> of file <FN>
  520. where <TN> is the trap number (decimal)
  521. <LN> is the line number (decimal)
  522. <FN> is the filename of the original program
  523. .DE
  524. .sp 1
  525. Trap numbers are subdivided as follows:
  526. .IP 1-27: 20
  527. EM-machine error, as described in [3]
  528. .IP 63:
  529. an unimplemented EM-instruction is used
  530. .IP 64-127:
  531. generated by compilers, runtime systems, etc.
  532. .IP 128-252:
  533. generated by user programs
  534. .NH 1
  535. IMPLEMENTATION
  536. .PP
  537. It will not be possible to run the entire Amsterdam Compiler Kit on a
  538. 8080-based computer system.
  539. One has to write a program on another
  540. system, a system where the compiler kit runs on.
  541. This program may be a mixture of high-level languages, such as
  542. C or Pascal, EM and 8080 assembly code.
  543. The program should be compiled using the compiler kit, producing 8080 machine code.
  544. This code should come available to the 8080 machine
  545. for example by downloading or
  546. by storing it in ROM (Read Only Memory).
  547. .sp 1
  548. Depending on the characteristics of the particular 8080 based system, some
  549. adaptions have to be made:
  550. .IP 1) 10
  551. In 'head_em': the base address, which is the address where the first
  552. 8080 instruction will be stored, and the initial value of the
  553. stackpointer are set to 0x1000 and 0x8000 respectivally.
  554. .br
  555. Other systems require other values.
  556. .IP 2)
  557. In 'head_em': before calling "_m_a_i_n", the environment
  558. pointer, argument vector and argument count will have to be pushed
  559. onto the stack.
  560. Since this back-end is tested on a system without any knowledge
  561. of these things, dummies are pushed now.
  562. .IP 3)
  563. In 'tail_em': proper routines "putchar" and "getchar" should
  564. be provided.
  565. They should write resp. read a character on/from the monitor.
  566. Maybe some conversions will have to be made.
  567. .IP 4)
  568. In 'head_em': an application program returns control to the monitor by
  569. jumping to address 0xFB52.
  570. If this is not the right way on your system, change it.
  571. .IP 5)
  572. In 'tail_em': the current version of the 8080 back-end has very limited I/O
  573. capabilities, because it was tested on a system that
  574. had no knowlegde of files.
  575. So the implementation of the EM-instruction 'mon' is very simple;
  576. it can only do the following things:
  577. .RS
  578. .IP Monitor\ call\ 1: 40
  579. Exit
  580. .IP Monitor\ call\ 3:
  581. read, always reads from the monitor.
  582. .br
  583. echos the read character.
  584. .br
  585. ignores file descriptor.
  586. .IP Monitor\ call\ 4:
  587. write, always writes on the monitor.
  588. .br
  589. ignores file descriptor.
  590. .IP Monitor\ call\ 5:
  591. open file, returns file descriptor -1.
  592. .br
  593. (compare chapter about TRAPS)
  594. .IP Monitor\ call\ 6:
  595. close file, returns error code = 0.
  596. .IP Monitor\ call\ 54:
  597. io-control, returns error code = 0.
  598. .RE
  599. .sp
  600. If the system should do file-handling the routine ".mon"
  601. should be extended thoroughly.
  602. .NH 1
  603. INTEL 8080 VERSUS ZILOG Z80 AND INTEL 8086
  604. .NH 2
  605. Introduction
  606. .PP
  607. At about the same time I develloped the back end
  608. for the Intel 8080 and Intel 8085,
  609. Frans van Haarlem did the same job for the Zilog z80 microprocessor.
  610. Since the z80 processor is an extension of the 8080,
  611. any machine code offered to a 8080 processor can be offered
  612. to a z80 too.
  613. The assembly languages are quite different however.
  614. .br
  615. During the devellopments of the back ends we have used
  616. two micro-computers, both equiped with a z80 microprocessor.
  617. Of course the output of the 8080 back end is assembled by an
  618. 8080 assembler. This should assure I have never used any of
  619. the features that are potentially available in the z80 processor,
  620. but are not part of a true 8080 processor.
  621. .sp 1
  622. As a final job, I have
  623. investigated the differences between the 8080 and z80 processors
  624. and their influence on the back ends.
  625. I have tried to measure this influence by examining the length of
  626. the generated code.
  627. I have also involved the 8086 micro-processor in this measurements.
  628. .NH 2
  629. Differences between the 8080 and z80 processors
  630. .PP
  631. Except for some features that are less important concerning back ends,
  632. there are two points where the z80 improves the 8080:
  633. .IP First, 18
  634. the z80 has two additional index registers, IX and IY.
  635. They are used as in
  636. .DS
  637. LD B,(IX+10)
  638. .DE
  639. The offset, here 10, should fit in one byte.
  640. .IP Second,
  641. the z80 has several additional instructions.
  642. The most important ones are:
  643. .RS
  644. .IP 1) 8
  645. The 8080 can only load or store register-pair HL direct
  646. (using LHLD or SHLD).
  647. The z80 can handle BC, DE and SP too.
  648. .IP 2)
  649. Instructions are included to ease block movements.
  650. .IP 3)
  651. There is a 16 bit subtract instruction.
  652. .IP 4)
  653. While the 8080 can only rotate the accumulator, the z80
  654. can rotate and shift each 8 bit register.
  655. .IP 5)
  656. Special routines are included to jump to near locations, saving 1 byte.
  657. .RE
  658. .NH 2
  659. Consequences for the 8080 and z80 back end
  660. .PP
  661. The most striking difference between the 8080 and z80 back ends
  662. is the choise of the localbase.
  663. The writer of the z80 back end chose index register IY as localbase,
  664. because this results in the cheapest coding of EM-instructions
  665. like 'lol' and 'stl'.
  666. .br
  667. The z80 instructions that load local 10, for example
  668. .DS
  669. LD E,(IY+10)
  670. LD D,(IY+11)
  671. .DE
  672. occupy 6 bytes and take 38 time periods to execute.
  673. The five corresponding 8080 instructions loading a local
  674. occupy 7 bytes and take 41 time periods.
  675. Although the profit of the z80 might be not world-shocking,
  676. it should be noted that as a side effect it may save some
  677. pushing and popping since register pair HL is not used.
  678. .sp 1
  679. The choise of IY as localbase has its drawbacks too.
  680. The root of the problem is that it is not possible to add
  681. IY to HL.
  682. For the EM-instruction
  683. .DS
  684. lal 20
  685. .DE
  686. the z80 back end generates code like
  687. .DS
  688. LD BC,20
  689. PUSH IY
  690. POP HL
  691. ADD HL,BC
  692. .DE
  693. leaving the wanted address in HL.
  694. .br
  695. This annoying push and pop instructions are also needed in some
  696. other instructions, for instance in 'lol' when the offset
  697. doesn't fit in one byte.
  698. .sp 1
  699. Beside the choise of the localbase, I think there is no
  700. fundamental difference between the 8080 and z80 back ends,
  701. except of course that the z80 back end has register pair BC
  702. and, less important, index register IX available as scratch registers.
  703. .sp 1
  704. Most of the PATTERNS in the 8080 and z80 tables are more or less
  705. a direct translation of each other.
  706. .NH 2
  707. What did I do?
  708. .PP
  709. To get an idea of the quality of the code generated by
  710. the 8080, z80 and 8086 back ends I have gathered
  711. some C programs and some Pascal programs.
  712. Then I produced 8080, z80 and 8086 code for them.
  713. Investigating the assembler listing I found the
  714. lengths of the different parts of the generated code.
  715. .br
  716. I have checked two areas:
  717. .IP 1) 8
  718. the entire text part
  719. .IP 2)
  720. the text part without any library routine, so only the plain user program
  721. .LP
  722. I have to admit that neither one of them is really honest.
  723. When the entire text part is checked, the result is disturbed
  724. because not always the same library routines are loaded.
  725. And when only the user program itself is considered, the result is
  726. disturbed too.
  727. For example the 8086 has a multiply instruction,
  728. so the EM-instruction 'mli 2' is translated in the main program,
  729. but the 8080 and z80 call a library routine that is not counted.
  730. Also the 8080 uses library routines at some places where the
  731. z80 does not.
  732. .sp 1
  733. But nevertheless I think the measurements will give an idea
  734. about the code produced by the three back ends.
  735. .NH 2
  736. The results
  737. .PP
  738. The table below should be read as follows.
  739. For all programs I have computed the ratio of the code-lengths
  740. of the 8080, z80 and 8086.
  741. The averages of all Pascal/C programs are listed in the table,
  742. standarized to '100' for the 8080.
  743. So the listed '107' indicates that the lengths
  744. of the text parts of the z80 programs that originally were Pascal programs,
  745. averaged 7 percent larger than in the corresponding 8080 programs.
  746. .DS C
  747. --------------------------------------------------
  748. | | 8080 | z80 | 8086 |
  749. --------------------------------------------------
  750. | C, text part | 100 | 103 | 65 |
  751. | Pascal, text part | 100 | 107 | 55 |
  752. | C, user program | 100 | 110 | 71 |
  753. | Pascal, user program | 100 | 118 | 67 |
  754. --------------------------------------------------
  755. .DE
  756. .TE
  757. The most striking thing in this table is that the z80 back end appears
  758. to produce larger code than the 8080 back end.
  759. The reason is that the current z80 back end table is
  760. not very elaborate yet.
  761. For instance it doesn't look for any EM-pattern longer than one.
  762. So the table shows that the preparations in the 8080 back end table
  763. to produce faster code (like recognizing special EM-patterns
  764. and permitting one byte registers on the fake-stack)
  765. was not just for fun, but really improved the generated code
  766. significantly.
  767. .sp 1
  768. The table shows that the 8080 table is relativelly better
  769. when only the plain user program is considered instead of the entire text part.
  770. This is not very surprising since the 8080 back end sometimes
  771. uses library routines where the z80 and especially the 8086 don't.
  772. .sp 1
  773. The difference between the 8080 and z80 on the one hand and the 8086
  774. on the other is very big.
  775. But of course it was not equal game:
  776. the 8086 is a 16 bit processor that is much more advanced than the
  777. 8080 or z80 and the 8086 back end is known to produce
  778. very good code.
  779. .bp
  780. .B REFERENCES
  781. .sp 2
  782. .IP [1] 10
  783. 8080/8085 Assembly Language Programming Manual,
  784. .br
  785. Intel Corporation (1977,1978)
  786. .IP [2]
  787. Andrew S. Tanenbaum, Hans van Staveren, E.G. Keizer and Johan W. Stevenson,
  788. .br
  789. A practical tool kit for making portable compilers,
  790. .br
  791. Informatica report 74, Vrije Universiteit, Amsterdam, 1983.
  792. .sp
  793. An overview on the Amsterdam Compiler Kit.
  794. .IP [3]
  795. Tanenbaum, A.S., Stevenson, J.W., Keizer, E.G., and van Staveren, H.
  796. .br
  797. Desciption of an experimental machine architecture for use with block
  798. structured languages,
  799. .br
  800. Informatica report 81, Vrije Universiteit, Amsterdam, 1983.
  801. .sp
  802. The defining document for EM.
  803. .IP [4]
  804. Steel, T.B., Jr.
  805. .br
  806. UNCOL: The myth and the Fact. in Ann. Rev. Auto. Prog.
  807. .br
  808. Goodman, R. (ed.), vol. 2, (1960), p325-344.
  809. .sp
  810. An introduction to the UNCOL idea by its originator.
  811. .IP [5]
  812. van Staveren, Hans
  813. .br
  814. The table driven code generator from the Amsterdam Compiler Kit
  815. (Second Revised Edition),
  816. .br
  817. Vrije Universiteit, Amsterdam.
  818. .sp
  819. The defining document for writing a back end table.
  820. .IP [6]
  821. Voors, Jan
  822. .br
  823. A back end for the Zilog z8000 micro,
  824. .br
  825. Vrije Universiteit, Amsterdam.
  826. .sp
  827. A document like this one, but for the z8000.