The UNCOL Problem - Computerphile

Key Takeaways

on computer file we just love provocative and mysterious titles and carrying on from the last time we spoke let's say this is going to be a chat about what it came to be called the on-call problem universal computer 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 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 uncore 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 uh it very soon became only 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 you'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 arrange those registers in a formal or informal stack others don't should we always assume that we have stack capabilities and i think as somebody pointed out to me i think ron ron knott 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 io so fairly soon the idea of finding one unique intermediate 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 zed code as part of his alcohol 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 there in lane 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 byte code in other words it was a sort of pseudo assembler with really like single byte op codes like a and zed and whatever and yes byte code became flavor of the month we all go down to bytecode well then what do you do well you've got choices you could either write an interpreter for bytecode um 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 could always compile the byte code um 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 it's still it was ideal for what james wanted to do but it's 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 by code is fairly low level what about if we move it up so we're getting more airy fairy heaven knows you might encounter haskell way up there somewhere classic example of course is the development of c plus and as many of you know as its name implies it goes beyond c it adds classes and all sorts of other features too c and the idea from bjarna strewstrap the inventor was that to get something going in the first instance at least he would of course do the obvious thing he his compiler would compile a c plus plus down to c and then you could put it just through an ordinary c compiler for the back end so you see his uncle 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 plus plus to do that yes it did but there are big problems with this approach once you broadcast the fact that actually c plus plus your mach one 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 be honest true stroke 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 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 as 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 well that can't be an issue can it yes it can um because this whole question of level of your intermediate code this thing gets me there why do i need to go direct let me give you another example not c plus 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 is a wonderful achievement in order to get a pdf the way you did it originally was you compiled your postscript 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 and indeed i often thought well the next program i write in postscript before i do any type setting as ordered by the customer i will get my program to solve ackerman's 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 doable you sometimes found that your pdf produced out of compiling postscript interstellar 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 postcode have no need for it is to give a direct route to pdf and they called it pdf writer back in the early days and then of course people not wanting to be bound into adobe quite rightly so fabulous what we need to do is to replicate something what distiller does we'll write utilities with names like ps2 pdf which you'll typically find in uh 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 say 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 he 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 a 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 the stallman and the gnu effort did such a wonderful job in creating for us gnu 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 actually had the nerve to develop something that i think they called intermediate 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 that apple and steve jobs always used to have it may have existed but it was done by a bunch of no hopers and until we discovered it packaged it marketed and put it for you you might as well think 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 that's an update variable a if i have the token so let's bring back friendly steve so we've now got a token and what we're going to say is that unless i've got the token i cannot access it delivers back the integer result in its local variable that it declares for itself for holding the answer and eventually of course look it's going to return