5fc5b3c32d
of modules that failed to translate in the library. |
||
---|---|---|
.. | ||
as | ||
cg | ||
cv | ||
dl | ||
libbc | ||
libcc | ||
libem | ||
libpc | ||
libsys | ||
ncg | ||
Action | ||
README | ||
Unisoft_bug |
The m68k2 back end is an EM code generator for the Motorola MC68000. It defines an integer to be 16 bits and a pointer to be 32 bits. At present it does not support floating point operations. (All EM floating point instructions are translated to the 68000 "trap" instruction.) The m68k2 back end generates code for the ACK 68000 assembler/linker. (The mnemonics recognized by this assembler can be found in "as/mach3.c"). As this assembler/linker does not define an object (.o) format, it can only link assembly files. Consequently, all library modules are stored as assembly files. Some parts of the back end are system dependent, i.e. they depend on the kind of target 68000 system. - The way to do a Unix system call may vary from system to system. For every system call you need to have an assembly routine that passes the arguments and the system call number to Unix. These routines should be put in the library file "lib/tail_mon". The distribution contains a tail_mon file tailored for UniSoft Unix (see directory "libsys"). Beware that several Unix systems (e.g. UniSoft Unix) use 4-byte integers, whereas the m68k2 back end produces code for 2-byte integers. In this case all system calls having an "int" parameter should convert their parameters to "long"s. - Most systems require some sort of "test for enough stack space" at the beginning of every procedure, to get around the "back up" problem. E.g. UniSoft Unix requires a "tst.b N(sp)" instruction This instruction is generated by the routines "prolog()" and "save" in "cg/mach.c". - The output of the ACK 68000 assembler/linker is an a.out file that has a different format as an a.out file on your system. (As most 68000 systems have different a.out formats, there is no such thing as "the" 68000 a.out format). So a program is needed to convert the ACK a.out format (i.e. a series of "emitrecs" as defined in "as/frame.c") to your a.out format (as defined in "/usr/include/a.out.h"). The 1-page program "dl/cv.c" does the job for UniSoft Unix. It probably need only be slightly modified for your system. Note that the program generates no text or bss segments, but only a data segment. If your target 68000 does not run Unix, but is e.g. a stand alone 68000, you will need a program to download the ACK a.out file. The program "dl/dl.c" produces Intel Hex format on standard output from an a.out file. - The EM runtime start-off ("libem/head_em.s") may have to be modified. It should call the procedure _m_a_i_n with parameters (argc,argv,envp). Usually, Unix will put these on top of the stack before starting the program. Note, however, that for 4-byte systems Unix will provide a 4-byte argc, while _m_a_i_n expects a 2-byte argc; so the value must be shortened to 2 bytes. The head_em also does a brk() system call to allocate the bss. (The size of the bss cannot be obtained from an ACK a.out file). The m68k2 code generator translates most EM instructions in line. For some complex EM instructions it uses assembly routines (stored in the library "libem/libem_s.a"). The generated code does not check for array bound errors, overflow in arithmetic operations or division by zero (the latter will cause a hardware trap). The code generator has the following register conventions: a7: stack pointer a6: local base pointer a0,a1,d0,d1,d2: scratch registers (d0 is also used for 2/4 bytes function results; d0 and d1 are used for 8 bytes function results) a2-a5,d3-d7: register variables.