tack-devel Mailing List for The Amsterdam Compiler Kit (obsolete) (Page 21)
Moved to https://github.com/davidgiven/ack
Brought to you by:
dtrg
Menu
▾
▴
tack-devel — Discussion for developers of the ACK.
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(4) |
Jul
(4) |
Aug
(6) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(10) |
Feb
(5) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(88) |
Aug
(15) |
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(1) |
| 2007 |
Jan
|
Feb
(8) |
Mar
(4) |
Apr
|
May
(32) |
Jun
(7) |
Jul
|
Aug
(2) |
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
(3) |
Apr
(2) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
|
Dec
(2) |
| 2009 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
(3) |
May
(1) |
Jun
(5) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
(9) |
Dec
(2) |
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(12) |
Sep
(13) |
Oct
(2) |
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
(2) |
May
(11) |
Jun
(7) |
Jul
(2) |
Aug
(3) |
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
(9) |
Mar
(7) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(8) |
Oct
(2) |
Nov
|
Dec
(2) |
| 2013 |
Jan
|
Feb
|
Mar
(7) |
Apr
(8) |
May
(23) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(2) |
Jul
(1) |
Aug
|
Sep
(13) |
Oct
(1) |
Nov
(3) |
Dec
(1) |
| 2015 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
(10) |
May
(11) |
Jun
(7) |
Jul
(2) |
Aug
|
Sep
(6) |
Oct
(21) |
Nov
(19) |
Dec
(3) |
| 2017 |
Jan
(15) |
Feb
(3) |
Mar
|
Apr
(3) |
May
(2) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(6) |
Apr
|
May
(1) |
Jun
(12) |
Jul
|
Aug
|
Sep
(10) |
Oct
(4) |
Nov
(1) |
Dec
|
| 2019 |
Jan
(2) |
Feb
(19) |
Mar
(36) |
Apr
(4) |
May
(8) |
Jun
(11) |
Jul
|
Aug
|
Sep
(3) |
Oct
(3) |
Nov
(4) |
Dec
(1) |
| 2020 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(2) |
| 2021 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(9) |
Mar
|
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
|
Dec
(1) |
| 2023 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2024 |
Jan
(3) |
Feb
(1) |
Mar
|
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
| 2025 |
Jan
(7) |
Feb
|
Mar
|
Apr
(10) |
May
(1) |
Jun
(2) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Gerald M. <gm...@cl...> - 2007-05-01 04:37:55
|
Hello, Using ack-6.0pre3. A broken link is created during the make. Details: using default target linux386 after completion of ./pm configure && ./pm : link created is broken; no directory or file exists here. /tmp/ack-temp/staging/lib/i80/descr -> TOPSOURCE/lib/i80/descr <--broken ls -R /tmp/ack-temp/staging/lib/i80 /tmp/ack-temp/staging/lib/i80: descr <--broken link The only entry in TOPSOURCE/lib/ is directory descr This error in "./pm install" is expected: .. ./lib/cpm/modula2.o ./lib/cpm/libmodula2.a tar: ./lib/i80/descr: Cannot stat: No such file or directory ./lib/cpm/libsys.a and another error message following on the above: .. tar: Error exit delayed from previous errors with best regards, Gerald |
|
From: David G. <dg...@co...> - 2007-03-11 21:30:55
|
Anup Datta wrote: [...] > Hi > I am completely new in linux, although i have worked with few different= > programming language in windows. I have installed ACK, i don't know > whether it's successfull or not. I don't know how to give the root path= > as some people suggest. > I just want to compile some .c and .s files using ACK. > Can anyone help plz..?? Sorry for the delay --- I'm afraid I got tied up in other stuff and misse= d your message. Firstly, I'm afraid that I'd have to recommend that if you wanted to get = stuff done, I wouldn't recommend using the ACK; it's simply not there yet. It c= an't generate runnable binaries for Linux. All it can do is cross compile for various other (obsolete) platforms. I'm working on making it produce code= for modern platforms but it's considerably more complicated than it looks. Secondly, which version of the ACK are you using? And what platforms do y= ou want to compile for? --=20 =E2=94=8C=E2=94=80=E2=94=80 =EF=BD=84=EF=BD=87=EF=BC=A0=EF=BD=83=EF=BD=8F= =EF=BD=97=EF=BD=8C=EF=BD=81=EF=BD=92=EF=BD=8B=EF=BC=8E=EF=BD=83=EF=BD=8F=EF= =BD=8D =E2=94=80=E2=94=80=E2=94=80 http://www.cowlark.com =E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80 =E2=94=82 "I have always wished for my computer to be as easy to use as m= y =E2=94=82 telephone; my wish has come true because I can no longer figure= out how to =E2=94=82 use my telephone." --- Bjarne Stroustrup |
|
From: Anup D. <dat...@ho...> - 2007-03-09 11:57:10
|
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV |
|
From: Anup D. <dat...@ho...> - 2007-03-07 00:49:29
|
<html><div style='background-color:'><DIV> <DIV class=RTE>Hi</DIV> <DIV class=RTE>I am completely new in linux, although i have worked with few different programming language in windows. I have installed ACK, i don't know whether it's successfull or not. I don't know how to give the root path as some people suggest.</DIV> <DIV class=RTE>I just want to compile some .c and .s files using ACK.</DIV> <DIV class=RTE>Can anyone help plz..??</DIV></DIV></div><br clear=all><hr>Don't just search. Find. <a href="http://g.msn.com/8HMAEN/2749??PS=47575" target="_top">MSN Search</a> Check out the new MSN Search!</html> |
|
From: David G. <dg...@co...> - 2007-02-25 23:29:38
|
I can't believe it's taken this long, but I've finally managed to get the= new build mechanism in enough shape to do a release. 6.0pre1 is a preview release of what will eventually be 6.0. It's a drastically stripped down version of the ACK designed to be a simple stat= ic compiler toolchain and nothing else; so there's no lint, interpreter, cod= e expander, fast compiler, etc. But it *does* include support for ANSI C, K= &R C, Pascal, Modula-2, Basic and Occam. Unfortunately, currently the available platforms is limited to one; the p= c86 platform is a very simple test architecture that generates 8086 boot flop= pies. I needed something simple to get started on. However, I believe that the = ACK is now the only compiler in the world that will produce an entire miniatu= re operating system from a stdio C program. Or even a Basic one... This has not had a lot of testing due to Sourceforge having shut down the= ir compiler farm. I know it compiles cleanly on Ubuntu Edgy Linux and OpenBS= D 4.0. You can get the source package from: http://sourceforge.net/project/showfiles.php?group_id=3D130811 I'd appreciate any comments. --=20 =E2=94=8C=E2=94=80=E2=94=80 =EF=BD=84=EF=BD=87=EF=BC=A0=EF=BD=83=EF=BD=8F= =EF=BD=97=EF=BD=8C=EF=BD=81=EF=BD=92=EF=BD=8B=EF=BC=8E=EF=BD=83=EF=BD=8F=EF= =BD=8D =E2=94=80=E2=94=80=E2=94=80 http://www.cowlark.com =E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80 =E2=94=82 "I have always wished for my computer to be as easy to use as m= y =E2=94=82 telephone; my wish has come true because I can no longer figure= out how to =E2=94=82 use my telephone." --- Bjarne Stroustrup |
|
From: David G. <dg...@co...> - 2007-02-13 23:18:42
|
Oliver Lehmann wrote: [...] > It is an old system built in east-germany in the end of the 80s... [...] It sounds... complex! But from ACK's point of view, you've got an OS runn= ing on the Z8000 that you want to generate binaries for, right? You have two options: - (a) you can use the ACK to compile ack.out .o files, then translate tho= se .o files into s.out files for your device, and then link them with your own = linker; - or (b) you can do everything with the ACK so that the ACK produces executables for your OS. Option (a) involves writing a ack.out to s.out translator --- not terribl= y hard. Option (b) involves porting the syscall library and the startup cod= e, and then writing a ack.out to executable translator (which if your OS use= s simple memory dumps is already done for you). This requires more work but= does produce a much cleaner result. (You can do 'ack -mp8000 hello.c' and run = the result.) Frankly, for now I'd probably recommend (a). I'm still figuring out the startup and runtime systems, which are gnarly. By using your system linke= r you don't need to worry about this. However, what you *do* need to worry abou= t are the calling conventions; the ACK is a bit strange and if it uses a differ= ent calling convention to your own compiler then you'll be out of luck. --=20 =E2=94=8C=E2=94=80=E2=94=80 =EF=BD=84=EF=BD=87=EF=BC=A0=EF=BD=83=EF=BD=8F= =EF=BD=97=EF=BD=8C=EF=BD=81=EF=BD=92=EF=BD=8B=EF=BC=8E=EF=BD=83=EF=BD=8F=EF= =BD=8D =E2=94=80=E2=94=80=E2=94=80 http://www.cowlark.com =E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80 =E2=94=82 "I have always wished for my computer to be as easy to use as m= y =E2=94=82 telephone; my wish has come true because I can no longer figure= out how to =E2=94=82 use my telephone." --- Bjarne Stroustrup |
|
From: Oliver L. <le...@an...> - 2007-02-11 20:59:45
|
David Given wrote: > Oliver Lehmann wrote: > [...] > > I now got the whole tack thing to compile and to install on my FreeBSD > > system. > > Sorry for the delay; I'm glad you have it working --- the old build mechanism > is particularly gnarly (I'm slowly working on a new one which should be vastly > improved). You can find a patch to get it to work on FreeBSD against the offical 5.6 tar.bz here - I guess some of it is FreeBSD specific, others shouldnt (like ack-5.6/util/ceg/as_parser/eval/eval.c) http://www.pofo.de/tmp/ack-5.6.diff -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ |
|
From: Oliver L. <le...@an...> - 2007-02-11 20:57:09
|
David Given wrote: > What platform are you trying to develop for? If it's an embedded system, it's > perfectly possible to abandon the ACK's libc and runtime and write your own > --- it's not very hard. It is an old system built in east-germany in the end of the 80s and I'm searching for a more decent compiler than the one which comes with the system (and is just some sort of buggy or "limited"). The system itself is made of an 8Bit part which runs with a Z80clone, offers a floppy controller for 4 floppies, and 4 serial ports, and a special serial port used for an EPROM programmer. The other part contains the Z8000 clone, offers 4 more serial port, and a special parallel port which is connected to a WDC controller (which is itself a z80 system) which is able to support up to 3 MFM harddisks. The 16Bit Part is connected to the 8Bit part via a bus system. Booting the 16 Bit part works by loading a special Zilog RIO clone-OS which jumps into the Z8000 loader where it's possible to boot up the UNIX called WEGA (Sys III clone) The system can also access the 8-bit devices (ports, eprommer, floppy) via the bus system while the 8bit part runs a piece of software the 16 bit part communicates with (probably inside the kernel or even more "low level") I'm now searching for a way to compile code on my FreeBSD system and have it able to run on this system. The systems object format is documented here: http://www.pofo.de/P8000/misc/s.out.h Greetings, Oliver PS: More about the system can be found here: http://www.pofo.de/P8000/ but I've to admint that most of it is in german language (all the manuals and so on) If you have even more interest you may try reading my P8000 blog http://www.pofo.de/P8000/blog/ ;) -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ |
|
From: David G. <dg...@co...> - 2007-02-11 20:26:52
|
Oliver Lehmann wrote: [...] > I now got the whole tack thing to compile and to install on my FreeBSD > system. Sorry for the delay; I'm glad you have it working --- the old build mecha= nism is particularly gnarly (I'm slowly working on a new one which should be v= astly improved). > I wonder how I now generate an ASM file, or even an executable for my > Z8000 system? > Lets say, I've a "test.c" file - how do I generate ASM code out of it, = or > get an executable (s.out format)? The short answer is: ack -mz8000 test.c *However*, the ACK doesn't compile for individual *architectures* (such a= s the Z8000) but for *platforms* (such as the Plexis). If you ask for the z8000= platform, you'll get code for a fairly generic and usually horribly obsol= ete platform. This has implications for the supplied libc, which (of course) contains platform-specific code. The above command line will link your program aga= inst the ACK's libc and C runtime and produce an executable for some device or= other. (I can't actually figure out one, because the Z8000 runtime appear= s to contain no comments! But you may be interested in looking at mach/z8000/libmon/mon.s, which contains the low-level I/O routines. It ap= pears to be designed for some simple embedded system, using sc 4 to write characters. Does that ring a bell?) What platform are you trying to develop for? If it's an embedded system, = it's perfectly possible to abandon the ACK's libc and runtime and write your o= wn --- it's not very hard. --=20 =E2=94=8C=E2=94=80=E2=94=80 =EF=BD=84=EF=BD=87=EF=BC=A0=EF=BD=83=EF=BD=8F= =EF=BD=97=EF=BD=8C=EF=BD=81=EF=BD=92=EF=BD=8B=EF=BC=8E=EF=BD=83=EF=BD=8F=EF= =BD=8D =E2=94=80=E2=94=80=E2=94=80 http://www.cowlark.com =E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80 =E2=94=82 "I have always wished for my computer to be as easy to use as m= y =E2=94=82 telephone; my wish has come true because I can no longer figure= out how to =E2=94=82 use my telephone." --- Bjarne Stroustrup |
|
From: Oliver L. <le...@an...> - 2007-02-11 16:45:16
|
Hi,
I now got the whole tack thing to compile and to install on my FreeBSD
system.
I wonder how I now generate an ASM file, or even an executable for my
Z8000 system?
Lets say, I've a "test.c" file - how do I generate ASM code out of it, or
get an executable (s.out format)?
I tried this, but the generated ASM file is not usable by asm on the target system:
root@kartoffel ack-i386> bin/z8000 test.c
root@kartoffel ack-i386> cat test.c
#include <stdio.h>
#define environ "fake"
#define __progname "test"
int main() {
printf("huhu\n");
exit(0);
}
root@kartoffel ack-i386> cat test.s
.sect .text; .sect .rom; .sect .data; .sect .bss
.extern _main
.sect .text
_main:
push *RR14, R13
ld R13, R15
push *RR14, $_1
calr _printf
add R15, $2
push *RR14, $0
calr _exit
ldk R14, $0
ld R15, R13
pop R13, *RR14
ret
.sect .data
_1:
.data2 26741
.data2 26741
.data2 2560
.sect .text
root@kartoffel ack-i386>
I tried the z8000 as supplied by tack, but it didn't worked...
root@kartoffel ack-i386> lib.bin/z8000/as test.s
unresolved references:
_exit
_printf
Exit 1
--
Oliver Lehmann
http://www.pofo.de/
http://wishlist.ans-netz.de/
|
|
From: Oliver L. <le...@an...> - 2007-02-10 09:27:49
|
Oliver Lehmann wrote: > root@kartoffel ack-i386> cat util/data/Out > lint-lib.ack em_data /mnt/files/ack-i386/lib.bin -I/mnt/files/ack-i386/h /mnt/files/tmp/Ack-5.5/util/data/em_flag.c /mnt/files/tmp/Ack-5.5/util/data/em_mnem.c /mnt/files/tmp/Ack-5.5/util/data/em_pseu.c /mnt/files/tmp/Ack-5.5/util/data/em_ptyp.c > expr: illegal option -- L Kind of easy to fix! lang/cem/lint/lpass2/lint has to be modified: LIBRARY=`expr "$1" : '-L\(.*\)'` has to be changed to LIBRARY=`expr -- "$1" : '-L\(.*\)'` To make expr not take "-L" as an argument. -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ |
|
From: Oliver L. <le...@an...> - 2007-02-09 18:58:18
|
Hi, while running INSTALL on my FreeBSD system (had to fix other things before) I'm stuck here: Failed for EM definition lint-library, see util/data/Out root@kartoffel ack-i386> cat util/data/Out lint-lib.ack em_data /mnt/files/ack-i386/lib.bin -I/mnt/files/ack-i386/h /mnt/files/tmp/Ack-5.5/util/data/em_flag.c /mnt/files/tmp/Ack-5.5/util/data/em_mnem.c /mnt/files/tmp/Ack-5.5/util/data/em_pseu.c /mnt/files/tmp/Ack-5.5/util/data/em_ptyp.c expr: illegal option -- L usage: expr [-e] expression "/mnt/files/tmp/Ack-5.5/util/data/em_flag.c", line 2: variable em_flag not used anywhere "/mnt/files/tmp/Ack-5.5/util/data/em_mnem.c", line 1: variable em_mnem not used anywhere "/mnt/files/tmp/Ack-5.5/util/data/em_pseu.c", line 1: variable em_pseu not used anywhere "/mnt/files/tmp/Ack-5.5/util/data/em_ptyp.c", line 4: variable em_ptyp not used anywhere mv: rename em_data.llb to /mnt/files/ack-i386/lib.bin/em_data.llb: No such file or directory *** Error code 1 Stop in /mnt/files/tmp/ack-i386/util/data. -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ |
|
From: Adam C. <ad...@cs...> - 2006-12-13 06:46:21
|
Hi, I was just wondering, has anyone has succeeded in installing ACK on Ubuntu Edgy? When I attempted to, the 'first' script failed with the cryptic message "t<5 digit number> not found". Every time I run the script, I get a similar message, with a different five-digit number. The parameters I entered in the 'first' script are those suggested in the README file in the top-level directory. Regards, Adam |
|
From: David G. <dg...@co...> - 2006-11-10 17:30:38
|
jmo...@uc... wrote: > Hello, > I'm having a difficult time getting ACK to compile a small C program to= > the 6800 cpu. Are there any examples of this? Unfortunately, contrary to what it says on the website, the ACK does *not= * contain a 6800 code generator. So you can use it as an assembler, but you= can't compile anything for it. Many apologies for misleading you; I misread the docs when I wrote the pr= oject descriptions, and haven't gotten around to updating them yet. I'm current= ly working (slowly) on the beta of the ACK 6, at which point the website wil= l get overhauled, but I should put a note in clarifying the state of the 6800 c= ode generator. --=20 =E2=95=AD=E2=94=80=E2=94=88David Given=E2=94=88=E2=94=80=E2=94=80McQ=E2=94= =80=E2=95=AE "A line dancer near a graduated cylinder, the =E2=94=82=E2=94=88 dg...@co...=E2=94=88=E2=94=88=E2=94=88=E2=94=88=E2=94= =82 blithe spirit inside some wheelbarrow, and a tomato =E2=94=82=E2=94=88(dg...@ta...)=E2=94=88=E2=94=82 are what made Amer= ica great!" --- received via spam =E2=95=B0=E2=94=80=E2=94=88www.cowlark.com=E2=94=88=E2=94=80=E2=94=80=E2=95= =AF |
|
From: <jmo...@uc...> - 2006-11-10 16:25:07
|
Hello,
I'm having a difficult time getting ACK to compile a small C program to
the 6800 cpu. Are there any examples of this?
My environment is Fedora Core 5 and the command I give is:
ack -m6800 -v -L -ly test.c
ack: Cannot produce the desired file from test.c
led /usr/local/lib/6800/tail_y test.c
led: can't read /usr/local/lib/6800/tail_y (fatal)
where the file 'test.c' is
int main()
{
int k=5;
int sum = 0;
int i;
for (i=0;i<3;i++)
{
sum += i*k;
}
}
Thanks!
James Moliere
|
|
From: David G. <dg...@co...> - 2006-10-12 21:54:09
|
The first public release of Prime Mover, my Lua-based build tool that I w= rote for the ACK, is now out. http://primemover.sourceforge.net Now that's done, I should hopefully have more time to spend on beating th= e ACK into shape. I hope to have a prerelease of the next version --- using the= PM-based build system --- out soon; I was mainly waiting until I'd got Pr= ime Mover into shape before doing that. Watch this space. --=20 +- David Given --McQ-+ "Gaping from its single obling socket was | dg...@co... | scintillating, many fauceted scarlet emerald..." | (dg...@ta...) | --- Jim Theis, _The Eye of Argon_ (spelling +- www.cowlark.com --+ original) |
|
From: tim k. <gt...@di...> - 2006-08-28 15:17:36
|
At 9:26 AM -0400 8/28/06, Nikolaos Kavvadias wrote: >tim kelly wrote: > >> There is a comment in one of the docs about features should have >> zero, one, or an infinite number of instances. A stack basis is >> zero registers. In keeping with this design philosophy, a change >> to registers for RISC CPUs would require infinite registers. >> Although initially this appears to be useful, I have come to >> believe that there is limited benefit to this change. > >That is a very interesting feature. Is it possible to only use the >stack notation for handling procedure entry/exit? >But maybe what you mean is that this feature is underdeveloped in ACK >and not really used much. ACK uses a few psuedo-registers, such as Program Counter, but as David pointed out, it's stack-based whenever possible. I would offer that semantically, an infinitely deep and tall stack is not different from an infinite number of registers divided about zero with positive registers being volatile and negative registers being non-volatile. Once the bookkeeping has been done on what is a parameter and what is a local variable, the implementation differs only in specifics, not concepts. I am, by the way, a big fan of registers (the more the better) and I'll take register-based operations over memory-based ones any day. >I'm thinking of performing this part (instruction scheduling) outside >ACK. My option would be SALTO >(http://www.irisa.fr/caps/projects/Salto/). It has a very strong API >for doing various things at "assembly" >level programs. I've only looked at it superficially, but it seems to me the greatest obstacle to efficient instruction scheduling is CPU manufacturers not publically (no NDA required) releasing the number of cycles each instruction takes (I don't like naming names, so I'll spell it out - I.B.M.). However, as long as CPU manufacturers are going to also make commercial compilers, I don't expect for this condition to change anytime soon. >> I'm gearing up for this, but at this time I've only gotten far >> enough to consider some of the ramifications. I've been working on >> using David Given's Prime Mover (pm) alternative to make (pm is >> waaaaay easier) for an OS independent bootloader (derived from the >> macppc boot.mac/ofwboot bootloader, I'm amazed at how bloated even >> something as simple as a bootloader can get). I hope to return to >> this sooner rather than later. > >It's nice to hear that there is interest in adding new features (the >new bootloader) and machines in ACK. The bootloader is separate from ACK, and I apologize if I mislead. I needed a good test of David's pm tool and the bootloader I've been modifying seemed like a good choice. I would like to make it much less OS- and compiler-dependent, which is requiring some decision making, such as how far beyond primitive types to do I allow it to go (I find it annoying to keep track of the dozens of different types of variables defined on top of primitives). David's pm tool made re-organizing the bootloader trivial, while make was a real unpleasant thorn in my side I was happy to discard. >From there I hope to use this bootloader both to bootstrap some BSD pieces that don't normally work together, and from there begin building ACK with PowerPC compiling on it. The BSD layer is there only long enough to bootstrap ACK into the toolchain end-to-end, as I have other plans (but ACK is my target toolchain). Some of the stuff I've documented at http://www.dialectronics.com/PowerPC http://www.dialectronics.com/OldWorldMacs http://www.dialectronics.com/bootloader http://www.dialectronics.com/Words tim Gregory T. (tim) Kelly Owner Dialectronics.com P.O. Box 606 Newberry, SC 29108 "Anything war can do, peace can do better." -- Bishop Desmond Tutu |
|
From: Nikolaos K. <nk...@ph...> - 2006-08-28 13:26:51
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 tim kelly wrote: > There is a comment in one of the docs about features should have > zero, one, or an infinite number of instances. A stack basis is > zero registers. In keeping with this design philosophy, a change > to registers for RISC CPUs would require infinite registers. > Although initially this appears to be useful, I have come to > believe that there is limited benefit to this change. That is a very interesting feature. Is it possible to only use the stack notation for handling procedure entry/exit? But maybe what you mean is that this feature is underdeveloped in ACK and not really used much. > > It is my belief that pipelining (instruction scheduling) will be > the biggest obstacle to fast code from ACK on RISC, not the issue > of stack versus registers. Since CISC also uses pipelining, it > would be my opinion that a feature enhancement to EM that offered > some additional hinting regarding how soon an instruction must > complete before the results are needed would be very well received. > Otherwise, the "looking-ahead" becomes a last mile issue repeated > for each architecture, when it could be more efficiently handled in > the centralized location of EM. I'm thinking of performing this part (instruction scheduling) outside ACK. My option would be SALTO (http://www.irisa.fr/caps/projects/Salto/). It has a very strong API for doing various things at "assembly" level programs. > I'm gearing up for this, but at this time I've only gotten far > enough to consider some of the ramifications. I've been working on > using David Given's Prime Mover (pm) alternative to make (pm is > waaaaay easier) for an OS independent bootloader (derived from the > macppc boot.mac/ofwboot bootloader, I'm amazed at how bloated even > something as simple as a bootloader can get). I hope to return to > this sooner rather than later. It's nice to hear that there is interest in adding new features (the new bootloader) and machines in ACK. Kind regards Nikolaos Kavvadias -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFE8u8OMPiy0tCWlz4RAkGaAKCjnF6RXf4/h0VJoMStlys9AOnQAgCgsiY1 fc8c4j98B9B5lo4+fuW0/Uk= =k07J -----END PGP SIGNATURE----- |
|
From: Nikolaos K. <nk...@ph...> - 2006-08-28 13:19:06
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Given wrotee: > There is an ARM2 backend, originally written for the Acorn > Archimedes. It's very non-standard (it uses R12 as the stack > pointer, for example) and produces extremely poor code. There's > also some 68k backends --- do they count as RISC these days? Well, the Coldfire 68k implementation is considered a *RISC* nowadays :) > One issue is that the ACK really likes to pass all parameters on > the stack. While this is ideal for stack-based machines it does > mean that on RISC machines, the ACK can't generate code that > matches the commonly used ABIs. I'm not sure whether this is worth > doing anything about --- I have a nasty suspicion that trying to > fix it would require major architectural changes. OTOH, I'll admit > that I haven't looked into that much yet. Hmm, I see. > (You may also be interesting in looking at TenDRA, which is a > compiler suite with a similar methodology but with a rather > different approach. It's got a C++ compiler, too.) I've had a look at TenDRA 2-3 years ago. IMO TenDRA is not table- and machine description -driven. It may be appropriate for developing a highly optimizing compiler for a target but not for quick retargeting (i.e. few man-weeks in my utopian world :) for new machines. My first thought was: hey that's even tougher than GCC! (laughs :) > Alas, most of this is lost in the mists of time --- but there are a > number of these and whitepapers in the ACK distribution; look on > the website under 'documentation' for them. The available docs you have mentioned, altough dated, look decent. > Um. I'm not actually surprised. The old build system is complicated > and unmaintainable, and is currently being replaced with a new > build system. (If you feel like trying it --- I'd be very > interested to know if it works on Cygwin --- then look back in the > mail archives for messages with 'CVS' in the subject line; this > will involve checking out head-of-CVS and building that.) I've fixed a few trivial references to a.out but there are more serious things going wrong. My impression is that it can be done. BTW i've already downloaded a recent CVS tarball (26-Aug-06). Thank you for your response. Kind regards Nikolaos Kavvadias -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFE8u06MPiy0tCWlz4RAs8dAKDJzDxgaq5rdNNF78HEEk47wWEP2wCbBo4P omUQSY29hf3+Uy8apvY5MWI= =+Fhv -----END PGP SIGNATURE----- |
|
From: tim k. <gt...@di...> - 2006-08-28 13:17:35
|
At 8:30 AM -0400 8/28/06, David Given wrote: >> 2. Is anybody working on a backend for a RISC machine (e.g. ARMv4 or >>ARMv5, MIPS >> or PowerPC)? > >There is an ARM2 backend, originally written for the Acorn Archimedes. It's >very non-standard (it uses R12 as the stack pointer, for example) and produces >extremely poor code. There's also some 68k backends --- do they count as RISC >these days? Sorry, my comment regarding what I was investigating/beginning referred to PowerPC. >One issue is that the ACK really likes to pass all parameters on the stack. >While this is ideal for stack-based machines it does mean that on RISC >machines, the ACK can't generate code that matches the commonly used ABIs. I'm >not sure whether this is worth doing anything about --- I have a nasty >suspicion that trying to fix it would require major architectural changes. >OTOH, I'll admit that I haven't looked into that much yet. IMNSHO, the ABI issues can rightfully be deferred until machine-dependent backends kick in. In the "prolog" EM generates to each function call the position of the parameters on the stack and what local variable space is required is stated. This should be easily translated to r3, r4, r5, et al for parameters and what non-volatile registers need to be saved off to the stack frame for local variables. (This does infer a step between EM and object code, one that generates the architectural assembly code.) Additional non-volatile registers and nested function calls are the responsibility of the caller and callee, so EM can be considered independently. I would even advocate against modifying EM to generate ABI-cognizant code. I've never seen any physical requirements that certain registers be used for certain actions. The requirement that r3-r9 be volatile and r1*-r31 be non-volatile is purely arbitrary on PowerPC, for example. I am aware that some RISC CPUs have single opcode instructions for saving off some or all non-volatile registers, but in the case of GPRs this actually turns out to take more cycles than manually saving them off if saving less than four or five registers (I forget the exact number), and in the case of Altivec/VMX, the opcode used to save the registers often ends up requiring that userland<->kernel jumps do a bitwise examination of what registers need to be preserved, instead of a save and restore limited to the registers being used (device drivers and vm page zeroing can be improved significantly by using Altivec, so there are legitimate reasons to use Altivec in the kernel). There's also the matter of variable number of registers within a PowerPC family. For example, stock Altivec CPUs have 32 Altivec registers, but the tri-core Xenon CPU powering the Xbox360 has 128 per core. Cell's PowerPC code has a "dual-thread" implementation, where two separate threads are scheduled on the same core, and the SPUs have "dual-instruction issue," one for math operations and one for memory operations but both execute simultaneously. Some of the high-end POWER CPUs have moved to a "register file," and also do register renaming in hardware. Too many variables to cover to attempt to implement a solution at the EM level. You would have to switch to an infinite register model and then use "register pressure" at the compiler level to match an ABI. Adherence to an ABI only requires that everyone adhere to it, so platforms that do not implement the ABIs ACK optimizes for would be at a disadvantage. I've been thinking more this morning about optimizing for RISC and I keep coming back to optimizing EM's stack for pipelining. Forth has several instructions for rearranging arguments on the stack, and if these are not present in EM they would be good additions. They could then be used for scheduling operations in advance and then actually inserting them in the stack when they are needed. This gives the compiler writer a chance to "look-ahead" for instruction scheduling. One-to-one table lookup replacements are also optimized at no cost. Alternatively, the MESSAGE instruction could be extended to give hints regarding local variables, such that when a local variable is used a MES instruction could say "I won't use this again for x operations." Just thinking out loud. tim Gregory T. (tim) Kelly Owner Dialectronics.com P.O. Box 606 Newberry, SC 29108 "Anything war can do, peace can do better." -- Bishop Desmond Tutu |
|
From: David G. <dg...@co...> - 2006-08-28 12:26:28
|
nk...@ph... wrote: [...] > 1. The "EM" intermediate language used in the compiler is a stack-based= one. > Has anybody a view on the limitations of the used IR for RISC target > machines? A data-flow tree or DAG-based representation would make more = sence > for RISC targets. I understand that at the time of ACK development earl= y 80's > there were no such machines (or where at their very start) but I'm just= > noting this anyway. >=20 > 2. Is anybody working on a backend for a RISC machine (e.g. ARMv4 or AR= Mv5, MIPS > or PowerPC)? There is an ARM2 backend, originally written for the Acorn Archimedes. It= 's very non-standard (it uses R12 as the stack pointer, for example) and pro= duces extremely poor code. There's also some 68k backends --- do they count as = RISC these days? One issue is that the ACK really likes to pass all parameters on the stac= k. While this is ideal for stack-based machines it does mean that on RISC machines, the ACK can't generate code that matches the commonly used ABIs= =2E I'm not sure whether this is worth doing anything about --- I have a nasty suspicion that trying to fix it would require major architectural changes= =2E OTOH, I'll admit that I haven't looked into that much yet. (You may also be interesting in looking at TenDRA, which is a compiler su= ite with a similar methodology but with a rather different approach. It's got= a C++ compiler, too.) > 3. Does anybody have links to related work e.g. theses related to porti= ng ACK > (either historical ones - 80's - or better more recent ones after the r= evival > and BSD licensing of the sources)? Alas, most of this is lost in the mists of time --- but there are a numbe= r of these and whitepapers in the ACK distribution; look on the website under 'documentation' for them. > 4. Creating the "INSTALL" script on Cygwin fails. This is due to an a.e= xe > generated (at the top-level dir of the sources) instead of the expected= Unix > a.out file: [...] Um. I'm not actually surprised. The old build system is complicated and unmaintainable, and is currently being replaced with a new build system. = (If you feel like trying it --- I'd be very interested to know if it works on= Cygwin --- then look back in the mail archives for messages with 'CVS' in= the subject line; this will involve checking out head-of-CVS and building tha= t.) --=20 +- David Given --McQ-+ "Gaping from its single obling socket was | dg...@co... | scintillating, many fauceted scarlet emerald..." | (dg...@ta...) | --- Jim Theis, _The Eye of Argon_ (spelling +- www.cowlark.com --+ original) |
|
From: tim k. <gt...@di...> - 2006-08-28 10:07:22
|
At 8:33 PM -0400 8/27/06, nk...@ph... wrote: >1. The "EM" intermediate language used in the compiler is a stack-based one. >Has anybody a view on the limitations of the used IR for RISC target >machines? A data-flow tree or DAG-based representation would make more sence >for RISC targets. I understand that at the time of ACK development early 80's >there were no such machines (or where at their very start) but I'm just >noting this anyway. There is a comment in one of the docs about features should have zero, one, or an infinite number of instances. A stack basis is zero registers. In keeping with this design philosophy, a change to registers for RISC CPUs would require infinite registers. Although initially this appears to be useful, I have come to believe that there is limited benefit to this change. EM is very good, as far as I can tell, at expressing hints regarding useage of local variables and parameters, to the point that I believe it is possible to write a RISC compiler without changing to an infinite register design. Since a pretty standard action in a procedure call is to create a stack frame anyways, the use of registers vs. memory can be reduced to an instruction level detail. A non-optimized version would track the variables by their location in the stack, mirroring the EM output, and then put the variable into a register when it needs to be operated on. (It should be noted that Tanenbaum and crew fully note that EM does not generate the most efficient object code.) Had RISC stayed with one instruction, one cycle, we wouldn't even have to worry about pipelining. It is my belief that pipelining (instruction scheduling) will be the biggest obstacle to fast code from ACK on RISC, not the issue of stack versus registers. Since CISC also uses pipelining, it would be my opinion that a feature enhancement to EM that offered some additional hinting regarding how soon an instruction must complete before the results are needed would be very well received. Otherwise, the "looking-ahead" becomes a last mile issue repeated for each architecture, when it could be more efficiently handled in the centralized location of EM. >2. Is anybody working on a backend for a RISC machine (e.g. ARMv4 or >ARMv5, MIPS >or PowerPC)? I'm gearing up for this, but at this time I've only gotten far enough to consider some of the ramifications. I've been working on using David Given's Prime Mover (pm) alternative to make (pm is waaaaay easier) for an OS independent bootloader (derived from the macppc boot.mac/ofwboot bootloader, I'm amazed at how bloated even something as simple as a bootloader can get). I hope to return to this sooner rather than later. tim Gregory T. (tim) Kelly Owner Dialectronics.com P.O. Box 606 Newberry, SC 29108 "Anything war can do, peace can do better." -- Bishop Desmond Tutu |
|
From: <nk...@ph...> - 2006-08-28 00:34:21
|
Hi there first of all congratulations on the hard work for getting ACK into shape and running on modern systems. I like the fact that it ACK is (almost) completely table-driven in regard to the backend system. I have a few questions regarding ACK development and usage. 1. The "EM" intermediate language used in the compiler is a stack-based one. Has anybody a view on the limitations of the used IR for RISC target machines? A data-flow tree or DAG-based representation would make more sence for RISC targets. I understand that at the time of ACK development early 80's there were no such machines (or where at their very start) but I'm just noting this anyway. 2. Is anybody working on a backend for a RISC machine (e.g. ARMv4 or ARMv5, MIPS or PowerPC)? 3. Does anybody have links to related work e.g. theses related to porting ACK (either historical ones - 80's - or better more recent ones after the revival and BSD licensing of the sources)? 4. Creating the "INSTALL" script on Cygwin fails. This is due to an a.exe generated (at the top-level dir of the sources) instead of the expected Unix a.out file: ./a.out: not found .: Can't open t3352: No such file or directory However, ack builds and installs OK on Linux RH 9.0 :) Kind regards Nikolaos Kavvadias |
|
From: David G. <dg...@co...> - 2006-08-23 12:35:39
|
tim kelly wrote: > While not directly related to the port of ACK, I was interested in know= ing > what standard/specification (ANSI, K&R, C89/99, et al) the ACK C langua= ge > "compiler" uses, and specifically what set of primitives are supported.= I > have to make some decisions about a project regarding supported types a= nd I > want to ensure as much compiler portability as possible. There are two C compilers; the ANSI one claims to conform to ANS X3.159-1989, and as K&R C was never effectively standardised (to my knowledge) it's hard to tell what it conforms to. The manual (available on the website) does, however, reference a number of major authorities, including Kernighan and Richie's book. --=20 +- David Given --McQ-+ "You cannot truly appreciate _Atlas Shrugged_ | dg...@co... | until you have read it in the original Klingon." | (dg...@ta...) | --- Sea Wasp on r.a.sf.w +- www.cowlark.com --+ |
|
From: tim k. <gt...@di...> - 2006-08-23 11:39:16
|
While not directly related to the port of ACK, I was interested in knowing what standard/specification (ANSI, K&R, C89/99, et al) the ACK C language "compiler" uses, and specifically what set of primitives are supported. I have to make some decisions about a project regarding supported types and I want to ensure as much compiler portability as possible. thanks in advance, tim Gregory T. (tim) Kelly Owner Dialectronics.com P.O. Box 606 Newberry, SC 29108 "Anything war can do, peace can do better." -- Bishop Desmond Tutu |
42 messages has been excluded from this view by a project administrator.
