We've been doing it all wrong

[Claudio Calvelli]

So... all INTERCAL compilers I know of take some INTERCAL program and
produce a program in another language as output. This is what all
compilers do and surely it's against the fundamental design principles
of the INTERCAL language?

I think I may just go and write something which takes C input and
produces an equivalent INTERCAL program. A *real* INTERCAL compiler.

(Yes, nurse, I'll take my injection now)

C

[ais523]

I was working on a backend to gcc a while back which produced brainfuck
as output. Unfortunately, I lost it in a computer crash, and it probably
doesn't link against modern gcc anyway.

Using similar techniques to produce INTERCAL would probably be a little
easier. However, it wouldn't have a structure very like the original C;
for example, it'd likely use one big array for all of memory.

It'd be more interesting to try to mirror the structure of the C program
somehow. The main issue I see is that C's pointer-and-malloc system
doesn't correspond to anything in INTERCAL-72; you can't create
something like a linked list in INTERCAL, for example, because the
number of allocations you can have visible in memory at any given time
is fixed by the program you have.

That said, you could probably form a "tape" out of STASH/RETRIEVE and
use that as your allocated memory / pointers (this assumes that we
have an INTERCAL implementation where you can STASH arrays and
allocate a new, differently-sized array over the stash without
invalidating the original). It'd mean an O(n) slowdown, but I don't see
why it couldn't work in theory. That'd let you emulate dynamic memory in
a way that would likely be usable for many C programs.

Library support is a large issue in its own right; it'd likely make the
most sense to start by aiming for a freestanding implementation (i.e.
which implements C algorithms, but with only minimal standard library
support).

Incidentally, it might make more sense to target an intermediate
representation such as LLVM, rather than C directly. That consists of
several rather lower-level operations which mostly translate into
INTERCAL directly (that is, if you "cheat" and use syslib).

--
ais523

[Claudio Calvelli]

On 2018-08-16, ais523 <ais...@nethack4.org> wrote:
> It'd be more interesting to try to mirror the structure of the C program
> somehow. The main issue I see is that C's pointer-and-malloc system
> doesn't correspond to anything in INTERCAL-72; you can't create
> something like a linked list in INTERCAL, for example, because the
> number of allocations you can have visible in memory at any given time
> is fixed by the program you have.

In CLC-INTERCAL (yes I know I've been delaying a new escape for about
10 years now...) you can use overloading to access any array whether
it's mentioned anywhere in the program or not. And of course these
arrays can be dimensioned and re-dimensioned so that would provide up
to 65535 pointers to dynamic memory. (I'll pretend not to think about
what this does to "constants" as a side effect).

The question whether it's a good idea to use the above... is probably
best not asked.

> Library support is a large issue in its own right; it'd likely make the
> most sense to start by aiming for a freestanding implementation (i.e.
> which implements C algorithms, but with only minimal standard library
> support).

I wouldn't implement things like dlopen(). Well, not unless a
sufficient amount of whisky results in more code like some parts of the
CLC-INTERCAL compiler (which work, I wrote them, but I have no idea why
they work).

> Incidentally, it might make more sense to target an intermediate
> representation such as LLVM, rather than C directly. That consists of
> several rather lower-level operations which mostly translate into
> INTERCAL directly (that is, if you "cheat" and use syslib).

That's just not enough fun.

C