--- /dev/null
+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"). It should be noted that some of these routines
+are not reentrant, because they save registers in a global common
+area (regsav).
+
+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.
public / ack.git / commitdiff