Re: [Tack-devel] Update on porting effort

[<u-...@ae...>]

On Thu, Feb 14, 2019 at 08:15:25AM +0000, Jacobs, C.J.H. via Tack-devel wrote:
> back when we developed ACK, we were worried about code size (in particular, the resulting size of binaries).
> We needed to have versions of the compiler running in 16-bit address space (OK, we had separate instruction and data spaces),
> but that meant that the compiler binary code had to fit in 64K, on systems that did not support shared libraries and such.
> Using stdio would make that virtually impossible, because even back then, that would add 8-16K to the binary size (I don’t
> remember exactly, but it was a lot). This is the reason that the ACK compiler front-ends don’t use printf, sprintf, FILE, etc.,
> or anything that internally uses those.

Hello Ceriel,

Thanks for the explanation.

I hope this compactness does not have to be sacrificed for the ansification.

It would be certainly exciting to have a version (as ack-4 was, or
possibly even the ack-5-derived minix ackpack?) capable of self-hosting on
16-bit platforms, not necessarily only on retrostyle pdp11-lookalikes but
why not on, say, risc-v rv16*? Run under Fuzix?

IMHO as long as there is a compact i/o library sufficient for the compiler
I would rather keep it - you never know when somebody would need to run
the compiler or its derivative on a constrained platform.

Rune