The Amsterdam Compiler Kit
15950f9c95
For now, a long long literal must have the 'LL' or 'll' suffix. A
literal without 'LL' or 'll' acts as before: it may become unsigned
long but not long long. (For targets where int and long have the same
size, some literals change from unsigned int to unsigned long.)
Type `arith` may be too narrow for long long values. Add a second
type `writh` for wide arithmetic, and change some variables from arith
to writh. This may cause bugs if I forget to use writh, or if a
conversion from writh to arith overflows. I mark some conversions
with (arith) or (writh) casts.
- BigPars, SmallPars: Remove SPECIAL_ARITHMETICS. This feature
would change arith to a different type, but can't work, because it
would conflict with definitions of arith in both <em_arith.h> and
<flt_arith.h>.
- LLlex.c: Understand 'LL' or 'll' suffix. Cut size of constant when
it overflows writh, not only when it overflows the target machine's
types. (This cut might not be necessary, because we might cut it
again later.) When picking signed long or unsigned long, check the
target's long type, not the compiler's arith type; the old check
for `val >= 0` was broken where sizeof(arith) > 4.
- LLlex.h: Change struct token's tok_ival to writh, so it can hold a
long long literal.
- arith.c: Adjust to VL_VALUE being writh. Don't convert between
float and integer at compile-time if the integer might be too wide
for <flt_arith.h>. Add writh2str(), because writh might be too
wide for long2str().
- arith.h: Remove SPECIAL_ARITHMETICS. Declare full_mask[] here,
not in several *.c files. Declare writh2str().
- ch3.c, ch3bin.c, ch3mon.c, declarator.c, statement.g: Remove
obsolete casts. Adjust to VL_VALUE being writh.
- conversion.c, stab.c: Don't declare full_mask[].
- cstoper.c: Use writh for constant operations on VL_VALUE, and for
full_mask[].
- declar., field.c, ival.g: Add casts.
- dumpidf.c: Need to #include "parameters.h" before checking DEBUG.
Use writh2str, because "%ld" might not work.
- eval.c, eval.h: Add casts. Use writh when writing a wide constant
in EM.
- expr.c: Add and remove casts. In fill_int_expr(), make expression
from long long literal. In chk_cst_expr(), allow long long as
constant expression, so the compiler may accept `case 123LL:` in a
switch statement.
- expr.str: Change struct value's vl_value and struct expr's VL_VALUE
to writh, so an expression may have a long long value at compile
time.
- statement.g: Remove obsolete casts.
- switch.c, switch.str: Use writh in case entries for switch
statements, so `switch (ll) {...}` with long long ll works.
- tokenname.c: Add ULNGLNG so LLlex.c can use it for literals.
|
||
|---|---|---|
| bin | ||
| doc | ||
| emtest | ||
| etc | ||
| examples | ||
| fast | ||
| fcc | ||
| first | ||
| h | ||
| include/_tail_mon | ||
| lang | ||
| lib | ||
| mach | ||
| man | ||
| modules | ||
| plat | ||
| tests/plat | ||
| util | ||
| .appveyor.yml | ||
| .clang-format | ||
| .distr | ||
| .drone.yml | ||
| .hgignore | ||
| .travis.yml | ||
| Action | ||
| build.lua | ||
| CHANGES | ||
| Copyright | ||
| Makefile | ||
| NEW | ||
| README | ||
| TODO | ||
THE AMSTERDAM COMPILER KIT V6.1pre1
===================================
© 1987-2005 Vrije Universiteit, Amsterdam
2018-02-23
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, B, 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
linuxmips produces ELF executables for little-endian MIPS32r2 Linux systems
cpm produces i80 CP/M .COM files
rpi produces Raspberry Pi GPU binaries
pdpv7 produces PDP/11 V7 Unix 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.
- (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 115MB free in /tmp (or some other temporary directory).
- about 15MB 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 -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 the PDP-11 dialect of B
.bas 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.
- When compiling together multiple B source files, you need to do some extra
work to initialise them properly otherwise your program will crash on
startup; see the ack(1) and abmodules(1) man pages.
- 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
2018-09-18