Contents | < Browse | Browse >
17F. bin/o2m
------------
If you have large pieces of assembly source that you'd like to use it would be
tedious at best to convert them all by hand to E's inline assembly.  o2m
allows you to simply have your favourite macro-assembler assemble it all to a
.o file, and o2, then will turn this .o file into a .m file for use with E.
If you have a file bla.o:

1> o2m bla

will produce bla.m.  However, the .o file will have to obey certain rules.  It
should consist of just one code-hunk with external definitions (XDEFs) for
each symbol you wish to reference from E, and no XREFs.  typically,

your source would look like:

	XDEF add__ii

add__ii:
	move.l	4(a7),d0
	add.l	8(a7),d0
	rts
	
this example shows a bit of assembly code that gets two arguments (hence
the two "i" for integer). arguments can be found on the stack, where
4(a7) is the last arg, 8(a7) the one before that etc.

Showhunk shows you this:

        hunk_unit: 
HUNK -1 hunk_name:  
        hunk_code: 12 bytes
        hunk_ext
          add__ii = $0

this type of .o file is easily transformed to .m by o2m:

/* this module contains 12 bytes of code! */

PROC add(a,b)


there are a couple of things to note:
- if your asm code uses D3-D7/A4/A5 you should probably save it.
- if a label doesn't have the "__" with an "i" for each function,
  it becomes a parameterless function. Don't worry if the label
  actually references data, you can simply get the address of this
  'proc' with {}, and use it as a ptr to your data.

theoretically, o2m could be used to link C code to E programs, however in
practise this is often not feasable.  If your C compiler allows you to 'tune'
the resulting .o files a bit, this might work.

some problems are:
- reference of C functions, for example _printf()
- reference of globals vars created by C startup code. C code
  may reference "DOSBase" as an XREF, whereas E's startup code makes 
  this value available somewhere on the stack
- call/register conventions.

I did manage to link a small C function to E that only does some computation,
and call it succesfully (this was done using MaxonC++, whose linker uses the
__ii convention for parameters also).