8ef7c31089
No change to linuxppc and qemuppc. They continue to run ego without any descr file. I copied m68020.descr to powerpc.descr and changed some numbers. My numbers are guesses; I know little about PowerPC cycle counts, and almost nothing about ego. This powerpc.descr causes most of the example programs to shrink in size (without descr -> with descr): 65429 -> 57237 hilo_b.osxppc -8192 36516 -> 32420 hilo_c.osxppc -4096 55782 -> 51686 hilo_mod.osxppc -4096 20096 -> 20096 hilo_p.osxppc 0 8813 -> 8813 mandelbrot_c.osxppc 0 93355 -> 89259 paranoia_c.osxppc -4096 92751 -> 84559 startrek_c.osxppc -8192 (Each file has 2 Mach segments, then a symbol table. Each segment takes a multiple of 4096 bytes. When the code shrinks, we lose a multiple of 4096 bytes.) I used "ack -mosxppc -O6 -c.so" to examine the assembly code for hilo.mod and mandelbrot.c, both without and with descr. This reveals optimizations made only with descr, from 2 ego phases: SP (stack pollution) and RA (register allocation). In hilo.mod, SP deletes some instructions that remove items from the stack. These items get removed when the function returns. In both hilo.mod and mandelbrot.c, RA moves some values into local variables, so ncg can make them into register variables. This shrinks code size, probably because register variables get preserved across function calls. More values stay in registers, and ncg emits shorter code. I believe that the ego descr file uses (time,space) tuples but the ncg table uses (space,time) tuples. This is confusing. Perhaps I am wrong, and some or all tuples are backwards. My time values are the cycle counts in latency from the MPC7450 Reference Manual (but not including complications like "store serialization"). In powerpc.descr, I give the cost for saving and restoring registers as if I was using chains of stw and lwz instructions. Actually ncg uses single stmw and lmw instructions with at least 2 instructions. The (time,space) for stmw and lmw would be much less than the (time,space) for chains of stw and lwz. But this ignores the pipeline of the MPC7450. The chains of stw and lwz may run faster than stmw and lmw in the pipeline, because the throughput may be better than the latency. By using the wrong values for (time,space), I'm trying to tell ego that stmw and lmw are not better than chains of stw and lwz. |
||
---|---|---|
bin | ||
doc | ||
emtest | ||
etc | ||
examples | ||
fast | ||
fcc | ||
first | ||
h | ||
include/_tail_mon | ||
lang | ||
lib | ||
mach | ||
man | ||
modules | ||
plat | ||
tests/plat | ||
util | ||
.clang-format | ||
.distr | ||
.hgignore | ||
.travis.yml | ||
Action | ||
build.lua | ||
CHANGES | ||
config.pm | ||
Copyright | ||
Makefile | ||
NEW | ||
README | ||
TakeAction | ||
TODO |
THE AMSTERDAM COMPILER KIT V6.1pre1 =================================== © 1987-2005 Vrije Universiteit, Amsterdam 2016-11-26 INTRODUCTION ============ The Amsterdam Compiler Kit is a complete compiler toolchain consisting of front end compilers for a number of different languages, code generators, support libraries, and all the tools necessary to go from source code to executable on any of the platforms it supports. This is an early prerelease of the apocryphal version 6.1 release. Not a lot is supported, the build mechanism needs work, and a lot of things are probably broken. However, what's there should be sufficient to get things done and to evaluate how the full 6.1 release should work. SUPPORT ======= Languages: ANSI C, Pascal, Modula 2, Basic. K&R is supported via the ANSI C compiler. Platforms: pc86 produces bootable floppy disk images for 8086 PCs linux386 produces ELF executables for PC Linux systems linux68k produces ELF executables for m68020 Linux systems linuxppc produces ELF executables for PowerPC Linux systems cpm produces i80 CP/M .COM files rpi produces Raspberry Pi GPU binaries INSTALLATION ============ The version 5.0 build mechanism has been completely rewritten. Installation ought to be fairly straightforward. Requirements: - an ANSI C compiler. This defaults to gcc. You can change this by setting the CC make variable. - flex and yacc. - GNU make. - Lua 5.1 and the luaposix library (used by the build system). - (optionally) ninja; if you've got this, this will be autodetected and give you faster builds. - (optionally) the qemu suite: if you have this installed, the build system will detect it automatically and run the test suites for the supported architectures. Get both the qemu-system-* platform emulators and the qemu-* userland emulators (only works on Linux). - about 40MB free in /tmp (or some other temporary directory). - about 6MB in the target directory. Instructions: - edit the Makefile. There's a small section at the top where you can change the configuration. Probably the only one you may want to edit is PREFIX, which changes where the ACK installs to. - Run: make ...from the command line. This will do the build. The make system is fully parallelisable. If you have a multicore system, install ninja and it'll use all your cores. If you don't have ninja, you can still use make for parallel builds with: make MAKEFLAGS='-r -j8' # or however many cores you have ...but frankly, I recommend ninja. - Run: sudo make install ...from the command line. This will install the ACK in your PREFIX directory (by default, /usr/local). The ACK should now be ready to use. USAGE ===== Currently I haven't sorted out all the documentation --- it's supplied in the distribution, but not all of it gets installed yet --- so here is a quickstart guide. The main command to use is 'ack'. This invokes the compiler and the linker. Some useful options include: -m<platform> build for the specified platform -o <file> specifies the output file -c produce a .o file -c.s produce a .s assembly file -O enable optimisation (optimisation levels go up to 6) -ansi compile ANSI C (when using the C compiler) -v be more verbose (repeatable) <file> build file ack figures out which language to use from the file extension: .c C (ANSI or K&R) .b Basic .mod Modula-2 .ocm Occam 1 .p Pascal .o object files .s assembly files .e ACK intermediate code assembly files For further information, see the man page (which actually does get installed, but is rather out of date). There are some (known working) example programs in the 'examples' directory. A sample command line is: ack -mlinux386 -O examples/paranoia.c GOTCHAS ======= There are some things you should be aware of. - Look at plat/<PLATFORMNAME>/README for information about the supported platforms. - The library support is fairly limited; for C, it's at roughly the ANSI C level, and for the other languages it's similar. - When compiling languages other than C, the ACK will usually look at the first character of the file. If it's a #, then the file will be run through the C preprocessor anyway. - BSD systems may need to up the number of file descriptors (e.g. 'ulimit -n 200') before the ACK will compile. - The ACK uses its own .o format. You won't be able to mix the ACK's object files and another compiler's. - The distribution contains *everything*, including the weird, ancient, archaic stuff that doesn't work any more and never will, such as the int EM interpreter and the assembler-linkers. Only some of it builds. Look for build.lua files. DISCLAIMER ========== The ACK is mature, well-tested software, but the environment in which it was developed for and tested under is rather different from that available on today's machines. There will probably be little in the way of logical bugs, but there may be many compilation and API bugs. If you wish to use the ACK, *please* join the mailing list. We are interested in any reports of success and particularly, failure. If it does fail for you, we would love to know why, in as much detail as possible. Bug fixes are even more welcome. The ACK is licensed under a BSD-like license. Please see the 'Copyright' file for the full text. You can find the mailing list on the project's web site: http://tack.sourceforge.net/ Please enjoy. David Given (davidgiven on Github) dg@cowlark.com 2016-11-26