carrying on from the last time we spoke let's say this is going to be a chat

about what came to be called the UNCOL problem. "Universal Computer [Oriented] Language" I think it stands for.

It was more specific than just any old computer language. It

was :" ... is there a unique intermediate language which would suit everybody?"

You know, not as high as C even and not quite down at the absolute binary level but

more like a sort of absolutely Universal Assembler - a pseudo-assembler. It's not

really hardware implemented on any machine but it's it's one that we can

all work with and every compiler in the whole world - all they would have to do is

produce the UNCOL language, if we can only agree what it is, and then every

system could talk to every other system at this agreed low level. Well, as you can

imagine, it doesn't work like that. It very soon became obvious that, yes, this

business of putting a level in there and saying: "We'll all compile to intermediate

code", is fine but when you start looking at what facilities it should have what

facilities it shouldn't have yo're up against the fact that computer hardware

designers like to do things their own way. I mean, numbers of registers? Might be

16, might be fewer that's no big deal Some of them have arranged those registers

[as pointers into] in a formal or informal stack. Others don't. Should we always assume that we

have stack capabilities? And I think somebody pointed out to me - I think Ron

Ron not who originally created these notes, he said "The thing in the end that

kills you is that they all do input-output differently; there's almost

no agreement about how you do I/O". So, fairly soon the idea of finding one

unique into me language had to be forgotten about.

But the idea of different intermediate languages at different levels of

sophistication really did gain traction in the 1980s. We mentioned that Steve

Bourne had his Z-code as part of his Algol 68 project, way back in the early 80s.

A little bit later on, I think it was in the 80s, many of you will

know this one better, James Gosling developed the language Java, in which

he decided that pointers were dangerous and should be hidden (but therein lies

another story). But the big thing that James made a feature of was to say:

I want my Java systems to compile down to what he called 'bytecode'. In other words

it was a sort of pseudo-assembler with really, like, single-byte op codes like A

and Z, and whatever. And, yes, bytecode became flavour of the month we all go down

to bytecode but then what do you do? Well, you've got choices. You could either

write an interpreter for bytecode which will be easy to change. It will be a

little slow, a bit big. If you really care passionately about having the ultimate

super-fast and efficient binary, you can always compile bytecode; get it

smaller and all that. So you had options. But the idea was that, yes, you would have

an intermediate code. Even so, it's not a one-size-fits-all. There's still ... it was

ideal for what James wanted to do but its extensibility to be a universal

panacea? Not so. You see, let me give you another good example of why some people

might want to move the semantic barrier a bit higher I mean bytecode is fairly

low-level. What about if we move it up so we're getting more airy-fairy?

heaven knows might encounter Haskell way up there somewhere!

Classic example of course is a development of C++ and as many of you

know, as its name implies, it goes beyond C. It adds classes and all sorts of

other features to C. And the idea from Bjarne Stroustrup,

the inventor, was that to get something going, in the first instance at least, he

would, of course, do the obvious thing. His compiler would compile C++ down to

C. And then you could put it just through an ordinary C compiler, for the back end.

So, you see, his 'UNCOL'is at a much higher level of sophistication than

pseudo-assembler type bytecode level. And you might say: "Oh well, that's great,

I mean, it's obviously suits C++ to do that". Yes, it did, but there are big problems

with this approach Once you broadcast the fact that

actually C++ your "Mark I" compiler is producing C under the hood, you will have

the devil's own job in convincing benevolent hackers, who think they can

generate better C code than Bjarne Stroustrup can, getting in behind the

scenes and messing about with the way he does classes for example. So, I suppose

what I'm saying more generally about this, is that very often you will have a

very good solution for a language system to establish a bridge-head, and to get

something working. But, in the longer run, you might want a more direct version

that isn't is prone to hacker intrusion, gross abuse or just things going a bit

wrong because of the nature of the intermediate language being so rich and

having a mind of its own. Now, you might say: "That can't be an issue, can it?" Yes, it can.

Because this whole question of 'level' of your intermediate code. This thing gets

me there. So, why do I need to go direct? Let me give you another example

Not C++ this time. Another well-known example for many of you is PDF. It's been

so well-established for so long now since 1989,

that many of you using it will not know that in the early days it came off the

back of Adobe's very successful language called PostScript. And PostScript was

there as, you know, the universal graphics language.

It drove laser printers it drove whatever It was a wonderful achievement. In order to

get a PDF - the way you did it originally was you compiled your PostScript with

with an Adobe-provided utility called Distiller. But the problem was in many

ways it was very graphically sophisticated but it was Turing Complete.

You could do anything in it [given enough memory] and, indeed, I often thought: "Well the next

program I wrote in PostScript, before I do any typesetting as ordered by the

customer, I will get my program to solve a commands function first. Can you

imagine the delay: "I'm sorry, I'm going to compute ackermann(3,1) before I turn my

attention to doing your miserable little piece of typesetting. But in principle

you could have done that - as long as it didn't run out of memory. But, you know,

I'm just saying this to make the silly point that that's perfectly do-able!

You sometimes found that your PDF, produced out of compiling PostScript with Distiller was

yards bigger than the input. Not very often but sometimes. So, there again, you

see, in order to stop abuse and to point the way to the future Adobe

very quickly said: "What we must do, for those that don't know about PostScript,

have no need for it, is to give a direct route to PDF. And they called it PDFwriter,

back in the early days. And then, of course, people don't not wantingto be

bounden to Adobe, quite rightly said: "Fabulous! What we need to do is to

replicate something of what Distiller does. We'll write utilities with names

like 'ps2pdf', which you'll typically find in PostScript offerings on Linux

and all this kind of stuff. But it makes the point that very often that

directness of approach gives you a good result

and stops people messing about under the hood and doing things which are

ridiculous and expensive. If you start saying: "No, from now on it's much quicker

to go direct, we know how to do it. Let's do it; let's keep it clean". So that is I

guess, I think, a feature. Still I keep reading stories of people using

intermediate codes for compiling programming languages who suddenly saying

"Well, 20 years down the line we think intermediate codes are bad. It's far

better to do it direct, in some other way" And all you can say, out of this. is that

every time you get into porting software you learn something every time about the

pros and cons of having an intermediate representation. Or do you jump over it

and go direct? There is no universal right answer. The more you look at the

scene at the moment about program language implementation the more you

realize that a huge number of the offerings out there might look to you

like straightforward point-to-point compilers you know: " ... I'm running on ...

whatever I'm running on at the moment ... I'm running on an ARM chip. It's all self-hosted on the

ARM chip. It compiles ARM code for further use on further ARM chips. It

doesn't do anything else!" Not true. If you look under the hood of gcc, of course

Stallman and the GNU effort did such a wonderful job in creating for us a new

version of 'cc'; when you look in there at the possible back-ends for different

architectures you realize it's really a cross-compilation system. You can compile

from anything to anything. Now other people, other than the GNU effort, got

there eventually and realized the same thing. I mean I think Microsoft, in the

mid 80s, did actually had the nerve to develop something that I think they

called "ntermediate Language". I don't know whether Microsoft did try and

actually copyright the phrase "Intermediate Language" but it's part of

the same mindset. it's not just them. {It's also] Apple and Steve Jobs

always used to have: "It may have existed[before] but it was done by a bunch o

no-hopers. And until we discovered it; packaged it; marketed it and put it up for you

you might as well think that it never existed!" And that was Jobs through and through.

But maybe all big computer companies have a little bit of this inside them:

" ... it didn't really exist, in a usable way, until *we* discovered it".