Structured Fortran - was Re: Self modifying code, lambda calculus

[Jay Jaeger]

On 9/23/2015 9:10 AM, Mouse wrote:
>> I am 100% certain, for example, that it would be possible to come up
>> with a C compiler for a 40K IBM 1410, which is in the set you
>> describe.
> 
> Possible?  Sure.  But it would be difficult; you would need to simulate
> a binary machine - C has a whole bunch of stuff that is defined to
> operate "as if" certain things are stored in binary.  Coupled with the
> way anything can be copied by using char-based types, you end up
> needing a binary machine, whether real or simulated.


An int just has to be able to store numbers of a certain magnitude.
Same with long.  You do have to be able to convert between longs (and
possibly ints) and addresses (*).  So, you make an int 5 digits (which
matches the natural length of addresses) and longs something like 10
digits.  You don't have to simulate anything, near as I can tell.  Then
the length of an int is 5 and a long is 10 (instead of the more typical
2 and 4).

I think what you are referring to by stating anything can be copied
using char-based types is (void) * - "I don't know what this points to".
 But using (void) to copy things will work fine, so long as they are
actually compatible in length and type - which is true of most any C
implementation.

One interesting design decision would be whether or not to try and
exploit the whole wordmark part of the architecture in native code when
doing assignments or comparisons of like types, as opposed to some kind
of threaded code implementation, and not bothering with wordmarks at
all.  A case could be made for either approach.  (The PDP-11 DOS FORTRAN
largely generated threaded code, BTW).

And, naturally, one would have to do some kind of stack emulation.

It might not be ANSI C (any more than FORTRAN II is FORTRAN IV or BDS C
was ANSI C), but one could certainly come up with a decent, useful C for
such a machine.

JRJ