ACK ANSI C compiler

ACK ANSI C compiler

[David Given]

[-- Attachment #1: Type: text/plain, Size: 687 bytes --]

I just thought that people here might be interested to know that I've been 
(slowly) working on resurrecting the old ACK compiler toolchain, used by 
Minix. It got open sourced a few years ago, under an extremely liberal BSD 
license.

http://tack.sourceforge.net/

The reason why I say this is that it is, as far as I know, the only decent 
free ANSI C i86 compiler. Tiny and small model only, unfortunately, but 
that's all that ELKS requires. It should certainly be better than bcc, but 
then a lot of things are...

-- 
+- David Given --McQ-+ 
|  dg@cowlark.com    | Wholesale theft is the sincerest form of flattery.
| (dg@tao-group.com) | 
+- www.cowlark.com --+ 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: ACK ANSI C compiler

[Hans]

Hi David,

Looks quite interesting and I will check it out when I have some free time. 
I am currently using the free Watcom compiler which supports the 8086 and 
upwards. I used this compiler (ver 10.0) years ago for a QNX based embedded 
system and it was quite good. The 8086 support is OKish, you have to fix 
some minor issues but nothing to difficult (like .386 pragma in the assembly 
listings). The full source code is available and the user group seems quite 
active.

See http://www.openwatcom.org/

To use it for my home grown system I wrote a simple runtime support and some 
basic library calls like putch/getch/sprintf/printf. I then wrote a monitor 
which included basic I/O interrupt handlers like int21/int10/int16.
By using a tiny model (.com) I avoid the requirement for a locator. I then 
translate the binary com file into an intel hex file and upload it to my 
board. So far it seems to work OK. When I have some more time I will put all 
this stuff on my website.

Does ACK compiles ELKS?

Regards,
Hans.


----- Original Message ----- 
From: "David Given" <dg@cowlark.com>
To: <linux-8086@vger.kernel.org>
Sent: Monday, August 15, 2005 5:12 PM
Subject: ACK ANSI C compiler

I just thought that people here might be interested to know that I've been
(slowly) working on resurrecting the old ACK compiler toolchain, used by
Minix. It got open sourced a few years ago, under an extremely liberal BSD
license.

http://tack.sourceforge.net/

The reason why I say this is that it is, as far as I know, the only decent
free ANSI C i86 compiler. Tiny and small model only, unfortunately, but
that's all that ELKS requires. It should certainly be better than bcc, but
then a lot of things are...

-- 
+- David Given --McQ-+
|  dg@cowlark.com    | Wholesale theft is the sincerest form of flattery.
| (dg@tao-group.com) |
+- www.cowlark.com --+ 

Re: ACK ANSI C compiler

[Harry Kalogirou]

> Does ACK compiles ELKS

No it doesn't. Actually it is going to be a nightmare to make it compile
under
ACK. But we probably should face the daemons...

Harry

Re: ACK ANSI C compiler

[David Given]

[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]

On Tuesday 16 August 2005 19:49, Harry Kalogirou wrote:
> > Does ACK compiles ELKS
>
> No it doesn't. Actually it is going to be a nightmare to make it compile
> under
> ACK. But we probably should face the daemons...

Apart from inline assembly, the biggest problem would most likely be 
generating the output binaries: the ACK's linker won't generate output files. 
Instead, the linker (it's called led) produces ack.out format files, just 
like any other object file, and relies on an architecture specific program to 
convert them into executable binaries.

(Given the vast number of different output formats, this is entirely 
reasonable, if a little unhelpful.)

For ELKS, you'd probably have to write two binary converters: one for the 
kernel, and one for the executables themselves. Neither of these would be 
particularly difficult, especially since ELKS binaries are heavily based on 
Minix binaries, and of course a Minix converter is supplied. 
(arch/i86/cv/cv.c if anyone's interested.)

-- 
"Curses! Foiled by the chilled dairy treats of righteousness!" --- Earthworm 
Jim (evil)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

ACK ANSI C Compiler

[Chad]

I've downloaded and compiled ACK, which took about 4.5minutes on my
p-m notebook - been looking for something like the 'em' targets for a
few days now.  Very nice, and I'm glad it's BSD licensed, too.

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.

Given the way ack works we might have real trouble with the kernel's
inline assembly - we'll have to move as much of the embedded assembly
as possible into assembly files, and make the ack linker deal with
them.  I'd have to look at the minix code to see how things are dealt
with there.

- Chad

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.

Re: ACK ANSI C Compiler

[David Given]

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 --+ 

[PATCH 1 DMA] Small Error Fixes

[Nanakos Chrysostomos]

[-- Attachment #1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #2: patch1.dma --]
[-- Type: application/octet-stream, Size: 732 bytes --]

Signed-off-by: Nanakos Chrysostomos <nanakos@wired-net.gr>

--- kernel/dma.c.orig	Wed Aug 17 16:56:24 2005
+++ kernel/dma.c	Wed Aug 17 16:58:01 2005
@@ -93,6 +93,7 @@ void free_dma(unsigned char dma)
 	printk("Trying to free DMA%u\n", dma);
     else if (!xchg(&dma_chan_busy[dma].lock, 0)) {
 	printk("Trying to free free DMA%u\n", dma);
+    } /* Nanakos Chrysostomos */
 }				/* free_dma */
 
 /* enable/disable a specific DMA channel */
@@ -235,8 +236,8 @@ int get_dma_residue(unsigned char dma)
     unsigned short count = 1 + dma_inb(io_port);
 
     count += dma_inb(io_port) << 8;
-
-    return (dmanr <= 3) ? count : (count << 1);
+    /* Nanakos Chrysostomos */
+    return (dma <= 3) ? count : (count << 1);
 }
 
 #endif

[PATCH 2 DIRECTHD] Small Error Fixes

[Nanakos Chrysostomos]

[-- Attachment #1: Type: text/plain, Size: 0 bytes --]



[-- Attachment #2: patch2.directhd --]
[-- Type: application/octet-stream, Size: 518 bytes --]

Signed-off-by: Nanakos Chrysostomos <nanakos@wired-net.gr>
--- arch/i86/drivers/block/directhd.c.orig	Wed Aug 17 17:05:54 2005
+++ arch/i86/drivers/block/directhd.c	Wed Aug 17 17:03:12 2005
@@ -214,8 +214,8 @@ void swap_order(unsigned char *buffer,in
 }
 
 #endif
-
-void out_hd(unsinged int drive,unsigned int nsect,unsigned int sect,
+/*Nanakos Chrysostomos*/
+void out_hd(unsigned int drive,unsigned int nsect,unsigned int sect,
 	    unsigned int head,unsigned int cyl,unsigned int cmd)
 {
     unsigned int port;

[PATCH 3 META] Small Error Fixes

[Nanakos Chrysostomos]

[-- Attachment #1: Type: text/plain, Size: 53 bytes --]

Commit these files with:
e.g

#patch -p0 < patch1.dma

[-- Attachment #2: patch3.meta --]
[-- Type: application/octet-stream, Size: 632 bytes --]

Signed-off-by: Nanakos Chrysostomos <nanakos@wired-net.gr>

--- arch/i86/drivers/char/meta.c.orig	Wed Aug 17 17:06:09 2005
+++ arch/i86/drivers/char/meta.c	Wed Aug 17 17:04:35 2005
@@ -64,14 +64,14 @@ int post_request(struct ud_driver *drive
     return 0;
 }
 
-
+/*Nanakos Chrysostomos*/
 static void do_meta_request(kdev_t device)
 {
+    int major = MAJOR(device);
     struct ud_driver *driver = get_driver(major);
     struct ud_request *udr;
     struct request *req;
     char *buff;
-    int major = MAJOR(device);
 
     printk("do_meta_request %d %x\n", major, blk_dev[major].current_request);
     if (NULL == driver) {