*** empty log message ***

mach/m68k2/README

@@ -0,0 +1,70 @@
+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.

mach/m68k2/libem/READ_ME

@@ -0,0 +1,5 @@
+The original EM library routines saved all registers
+(including scratch registers) in global data; hence they
+were not reentrant.
+The new routines do not save registers d0,d1,d2,a0 and a1.
+They are reentrant.