Re: ACK ANSI C Compiler

[David Given <dg@cowlark.com>]

On Wednesday 17 August 2005 04:20, Chad wrote:
[...]
> Getting ELKS user space apps working will mostly be a library issue -
> the convertor shouldn't be a big deal.  In fact, 'file' thinks a.out
> is a Linux-8086 executable already.  It looks like we can either port
> the bin86 libc or adapt included (minix?) libc to make ELKS system
> calls.

There are two ways you can do a system library with ACK:

1. You can port a i86-native libc, which uses fragments of inline assembly to 
make system calls. This is the way bcc and gcc work.

2. You can use the ACK's own syscall interface (which it calls monitor calls). 
The underlying intermediate code has a special opcode that performs a monitor 
call; the semantics are numbering are nearly identical to V7 UNIX, so it 
might be a good match to ELKS. The ACK then has a portable libc, written in 
EM assembly, that uses monitor calls for its underlying functionality. The 
advantage of this approach is that (a) it's less work, and (b) all the ACK's 
supported languages suddenly start working. The disadvantage is that the libc 
will probably be slightly slower than a hand-tweaked i86 libc.

See section 8.2 of the em docs for information about the monitor calls.

[...]
> OBCrazyTalk: With particularly twisted hacks of em, and a multi-task
> interpreter, and some *really* tight and small code, something
> ELKSlike might, just might run on a Z80... ;)  It would certainly run
> under regular Linux as a process, though.

There's a Z80 back end, but it's in pretty poor shape, and generates 
substantially worse code than the 8080 back end!

(Incidentally, if you're interested, please joing the ACK mailing list!)

-- 
+- David Given --McQ-+ "They laughed at Newton. They laughed at Einstein.
|  dg@cowlark.com    | Of course, they also laughed at Bozo the Clown."
| (dg@tao-group.com) | --- Carl Sagan
+- www.cowlark.com --+