This changes the BDOS call from CPM_BDOS_CONSOLE_INPUT to
CPN_BDOS_READ_CONSOLE_BUFFER. This allows commands like ^H to delete
characters and ^C to exit to CCP. This is more like how Unix read(2)
uses canonical mode of termios to read a line.
This change has a disadvantage: the user buffer to read(2) must now be
large enough for an entire line. This is because CP/M, unlike Unix,
lacks a kernel buffer to hold the rest of the line. If you use a
buffered input library like stdio to call read(2), then it works; but
if you try to read part of a line or a single character, then it
doesn't work.
Change from `uread(0, c, 1)` to `read(c)`, so input goes through
libpc's buffer. If input is a tty in Unix, this reduces the number of
read(2) system calls from one per character to one per line.
This change will become necessary in CP/M when I enable the line
editor.
Add a variable %{ackldflags} so I can pass `-fp`. This change seems
to cause the build to relink every ackprogram, because the link now
needs to use %{ackldflags} even if the flags are empty.
mandelbrot_c_cpm runs in YAZE-AG; startrek_c_cpm doesn't run because
it doesn't fit in the 16-bit address space.
This drops 124 bytes from the mandelbrot command (from 15015 to 14891
bytes) but has almost no effect on performance; the command takes
about 144 seconds (in YAZE-AG) both before and after optimizing libfp.
Old .o files stop working if they use floating point. One must
recompile those files. Old files don't call libfp in the correct way,
and may use symbols that I removed from libem. I don't keep old
symbols in libem/flp.s, because a program that pulls both libfp and
flp.s would get "multiply defined" errors in the linker.
I teach mach/i80/ncg/table to use libfp by copying or adapting the
patterns from mach/i86/ncg/table. I did not test all the patterns,
but I did use `ack -mcpm -fp -O4` to compile examples/mandelbrot.c,
then I ran it in the emulator YAZE-AG. It worked, but it was slow.
This library is for software floating point. The i80 back end has
never implemented floating point, and might not be ready for libfp.
This commit only builds libfp without using it.
I edit first/build.lua and plat/build.lua to allow `ack -c.s`, then
use FP.script to edit the assembly code. I edit FP.script so it
writes the edited assembly code to stdout, not to the input file.
CS eliminates outer expressions before inner ones, as `x * y * z`
before `x * y`. It does this by reversing the order of expressions in
the code. This almost always works, but it sometimes doesn't work if
a STI changes the value number of a LOI. In code like `expr1 LOI
expr2 STI expr2 LOI`, CS might eliminate the inner `expr2` before the
outer `expr2 LOI`. This caused a read after free because the
occurrence of `expr2 LOI` pointed to the eliminated lines of `expr2`.
This bug went unnoticed until my recent changes caused CS to crash
with a double free. I did not get the crash in OpenBSD, but I saw the
crash in Travis, then David Given reproduced the crash in Linux. See
the discussion in https://github.com/davidgiven/ack/pull/73
the -U command line option, and one via file scanning. Turns out only the
second would increment the number of global names, so adding names with -U
would cause names found via scanning to fall off the end of the list! This
wouldn't cause linker errors because fixups don't use the list, but would cause
the generated symbol table in the output to be incorrect.
This got caught by MALLOC_OPTIONS=S in OpenBSD. The B compiler filled
the buffer while compiling hilo.b. Then realloc moved the buffer and
unmapped the old buffer. The compiler tried to read the old buffer
and segfaulted.
With this change, I built and ran ack on a big-endian PowerPC Linux
machine. I used gcc 4.9.4 to build ack, and I only built the linuxppc
back end.
Before this change, wr_ranlib() corrupted a value by changing it from
0x66 to 0x66000066. This value was too big, so led made a fatal
error, "bad ranlib string offset".
Add more page numbers from PowerPC version 2.01. Remove "xnop" not in
2.01, add "mtcr" from 2.01. Add "lwarx" and the other instructions
from Book II. I did not try all the newly added instructions, but
these seem to work: dcbt, dcbtst, icibi, isync, lwarx, stwcx., mftb,
mftbu
In man/powerpc_as.6 (not installed), add a summary of the registers
and addressing modes (like in i386_as.6), describe short forms, update
description of hi16/ha16, add CAVEATS about instructions that some
processors can't run.
Enable this in CS for PowerPC; disable it for all other machines.
PowerPC has no remainder instruction; the back end uses division to
compute remainder. If CS finds both a / b and a % b, then CS now
rewrites a % b as a - b * (a / b) and computes a / b only once. This
removes an extra division in the PowerPC code, so it saves both time
and space.
I have not considered whether to enable this optimization for other
machines. It might be less useful in machines with a remainder
instruction. Also, if a % b occurs before a / b, the EM code gets a
DUP. PowerPC ncg handles this DUP well; other back ends might not.
In ego, the CS phase may convert a LAR/SAR to AAR LOI/STI so it can
optimize multiple occurrences of AAR of the same array element. This
conversion should not happen if it would LOI/STI a large or unknown
size.
cs_profit.c okay_lines() checked the size of each occurrence of AAR
except the first. If the first AAR was the implicit AAR in a LAR/SAR,
then the conversion happened without checking the size. For unknown
size, this made a bad LOI -1 or STI -1. Fix by checking the size
earlier: if a LAR/SAR has a bad size, then don't enter it as an AAR.
This Modula-2 code showed the bug. Given M.def:
DEFINITION MODULE M;
TYPE S = SET OF [0..95];
PROCEDURE F(a: ARRAY OF S; i, j: INTEGER);
END M.
and M.mod:
(*$R-*) IMPLEMENTATION MODULE M;
FROM SYSTEM IMPORT ADDRESS, ADR;
PROCEDURE G(s: S; p, q: ADDRESS; t: S); BEGIN
s := s; p := p; q := q; t := t;
END G;
PROCEDURE F(a: ARRAY OF S; i, j: INTEGER); BEGIN
G(a[i + j], ADR(a[i + j]), ADR(a[i + j]), a[i + j])
END F;
END M.
then the bug caused an error:
$ ack -mlinuxppc -O3 -c.e M.mod
/tmp/Ack_b357d.g, line 57: Argument range error
The bug had put LOI -1 in the code, then em_decode got an error
because -1 is out of range for LOI.
Procedure F has 4 occurrences of `a[i + j]`. The size of `a[i + j]`
is 96 bits, or 12 bytes, but the EM code hides the size in an array
descriptor, so the size is unknown to CS. The pragma `(*$R-*)`
disables a range check on `i + j` so CS can work. EM uses AAR for the
2 `ADR(a[i + j])` and LAR for the other 2 `a[i + j]`. EM pushes the
arguments to G in reverse order, so the last `a[i + j]` in Modula-2 is
the first LAR in EM.
CS found 4 occurrences of AAR. The first AAR was an implicit AAR in
LAR. Because of the bug, CS converted this LAR 4 to AAR 4 LOI -1.
