Hacker News Reader

Hacker News

Comment by no_protocol | Hacker News Reader

Parent Full thread

no_protocol

A great number of familiar concepts are described here in just 2 pages:

- Subroutines

- Modularity

- Unit testing

- Reusable libraries

- Documentation

- `goto`/`return`

- Debugging

The tone seems to place this writing as instructive -- someone who wanted to write a programme at the time could refer to this document for hints at what to do. Very interesting window into the past.

I haven't quite decoded exactly what the modern formulation of an `interpretive routine` is. Is it the same as the layer we would now call the "instruction set architecture" that sits above some "microcode" operations? Where some instructions do more work than others behind the scenes. It also seems to have some relation to "just-in-time compilation", just at a lower level than the current systems.

View on HN

Not only that, but using completely familiar language we still use in software engineering today.

> I haven't quite decoded exactly what the modern formulation of an `interpretive routine` is.

Here is one, though you can take the "modern" with a grain of salt:

  printf("%s = %d\n", name, value);

The format string is interpreted.

A new-ish function that interprets is posix_spawn: http://pubs.opengroup.org/onlinepubs/009695399/functions/pos...

The actions parameter specifies instructions to be run inside the kernel, using a limited vocabulary. This is used to do things that are traditionally done in fork/exec code, like duping and closing file descriptors and such.

> I haven't quite decoded exactly what the modern formulation of an `interpretive routine` is.

The example given is probably the closest to evaluating a string as a series of operations on parameters passed to a function. So say evaluate('p0 * p1 + p2', p0, p1, p2). The proper evaluation of arithmetic expressions is quite hard but a recurring theme no matter what language you work with, so it would make sense to abstract that out and do it once and (hopefully) well.

The 'orders' are then the operators.

Keep in mind that this was written well before high level languages were common and that such subroutines were handcrafted pieces of code likely operating on a series of fixed memory locations rather than parameters passed on the stack.

A bit like you would do this in BASIC before structured versions of basic came along, set a bunch of global variables, GOSUB, read back the result from some other global variable.

This sort of arrangement made composition a very interesting and sometimes maddening affair.

Another way to read that fragment is as the beginnings of a high level interpreted language, I think that is given extra weight because of the debug possibilities and the fact that the program 'retains control'.

I did some more research after that post and found this explanation at [1]:

> Turing put this as follows: "an interpretive routine is one which enables the computer to be converted into a machine which uses a different instruction code from that originally designed for the computer".

It goes on to describe how Wheeler simulated a number of capabilities that EDSAC's hardware did not provide. Some more description of that is available at [2].

Finally, I found [3], which includes an actual listing of an interpretive routine for the EDSAC and a more detailed explanation. See page 47-48.

After seeing [3] it's like writing a bunch of EDSAC assembly then partway through, you want to work with floating point numbers, which no EDSAC instructions support, so you use a special code indicating your next several instructions are written for the "EDSAC+Float" machine instead, and they are interpreted that way.

This final document I located was quite interesting.

In the end, I think "interpretive subroutines" are perhaps closest to being like "virtual machines" or "emulators". Because there weren't really high level languages at the time, the concept in their mind is more like writing code for a different machine. It is like a high level language, in that it expands the set of operations that the programmer can use to speak with the computer.

[1]: https://books.google.com/books?id=uflV0_q-FEUC&lpg=PA190&ots...

[2]: https://books.google.com/books?id=AoWrCAAAQBAJ&lpg=PA33&ots=...

[3]: https://archive.org/details/programsforelect00wilk

Thank you for doing all that work!

> handcrafted pieces of code likely operating on a series of fixed memory locations rather than parameters passed on the stack.

You mean like Fortran?

> I haven't quite decoded exactly what the modern formulation of an `interpretive routine` is.

It sounded like a description of an interpreter used to emulate the behavior of the host machine, while allowing more tracing of the algorithm. One of the arguments to the interpreter would be the program data to be interpreted.

Even higher-order functions are mentioned!

Does anybody know where this article was originally published?

Reply on news.ycombinator.com