shepherd@euroies.UUCP (Roger Shepherd INMOS) (06/07/86)
In article <438@ccird1.UUCP> Rex Ballard writes: > All High level languages do is attempt to organize the > macros and subroutines that might otherwise be written in > assembler. They also provide some convenient and well > standardized procedures and parameter passing conventions. I disagree with view. A high level language should be more than a glorified macro assembler. It is possible to design a high level language so that it actually has a clean, coherent and useful semantics. It can then be used as a way of describing algorithms mathematically. Such langauges can even be compiled! Of course, very few existing HLLs have such a semantics. However, I have been useing one that does and one which compiles effeciently onto a processor. Furthermore, its mathematical semantics is useful and COST-EFFECTIVE. One of the projects which I have been involved with is the production of a HLL coded version of the IEEE Floating Point standard. Out initial efforts at writing and testing said package were very labourious and insecure. We tried testing the package by comparing it with what were believed to be correct implementations. This lead us to find an error in a currently available floating point chip! The adoption of formal mathematical methods (to which our HLL is suseptable) means that a correct version was produced in a few weeks. -- Roger Shepherd, INMOS Ltd, WHITEFRIARS, LEWINS MEAD, BRISTOL, UK USENET: ...!euroies!shepherd PHONE: +44 272 290861
rb@ccird1.UUCP (Rex Ballard) (06/12/86)
In article <316@euroies.UUCP> shepherd@euroies.UUCP (Roger Shepherd INMOS) writes: >In article <438@ccird1.UUCP> Rex Ballard writes: >> All High level languages do is attempt to organize the >> macros and subroutines that might otherwise be written in >> assembler. They also provide some convenient and well >> standardized procedures and parameter passing conventions. > >I disagree with view. A high level language should be more than a glorified >macro assembler. It is possible to design a high level language so that >it actually has a clean, coherent and useful semantics. It can then be used >as a way of describing algorithms mathematically. Such langauges can even >be compiled! In a sense, I agree with you. What you're describing is the human->compiler side of what a language should be. I am describing what the compiler->machine side should be. How good the interface between the two view is, is a good definition of the quality of a compiler. If restricitions are loose enough reguarding the nature of the variables, definitions, and operators, one could express algorythms in "structured english" (as opposed to the hodge-podge we normally atribute to the language), and have it compiled into a sequence of subroutines, macro expansions, and instructions which could be executed by a computer. On the other hand, "structured english" is a little tedious to type. Perhaps a "Decompiler" could translate 'C' code tokens into structured english :-). Not only could it be compiled into instructions, it could also be compiled into useful data bases, flow charts, structure charts, and even "design completers" which could find common primitives in complex systems, and express them in the same structured language. These 'design completers' are more commonly referred to as optimization, but often the input, as well as the assembler could be optimized by machine, leaving only the most commonly executed parts of the code to be "super-optimized" by hand, or even hardware. >Of course, very few existing HLLs have such a semantics. However, I have been >useing one that does and one which compiles effeciently onto a processor. Which language is this? >Roger Shepherd, INMOS Ltd, WHITEFRIARS, LEWINS MEAD, BRISTOL, UK Nice company, looking forward to seeing more info on your products.
de@comp.lancs.ac.uk (David England) (06/17/86)
In article <473@ccird1.UUCP> rb@ccird1.UUCP (Rex Ballard) writes: >In article <316@euroies.UUCP> shepherd@euroies.UUCP (Roger Shepherd INMOS) writes: >>In article <438@ccird1.UUCP> Rex Ballard writes: >>> All High level languages do is attempt to organize the >>> etc >> >>I disagree with view. A high level language should be more than a glorified >>macro assembler. >>etc > >In a sense, I agree with you. What you're describing is the human->compiler >side of what a language should be. I am describing what the compiler->machine >side should be. > ... and as far as the human->compiler side of things is concerned the days of languages are numbered. Visual programming and spatial data management are the "languages" of the future. In five years time there should be no net.lang* :-). If this was a bit mapped screen I would draw this article as a vt100 icon being thrown into a trash can icon :-). -- Dave uucp: ...!mcvax!ukc!dcl-cs!de arpa: de%lancs.comp@ucl-cs "I like to go where the action is. Move in, move out. And no paper work."
henry@utzoo.UUCP (Henry Spencer) (06/17/86)
> > All High level languages do is attempt to organize the > > macros and subroutines that might otherwise be written in > > assembler... > > ...A high level language should be more than a glorified macro assembler... In particular, a high-level language should do its best to check the programmer's code for errors -- something no macro assembler will ever be able to do very well. Features like type checking are not mere frills; they catch many errors. Decent high-level languages give the translator a much better grasp of what the programmer is doing, so it can point out inconsistencies. (It can also optimize the code better -- most hand-written assembler is not highly optimized, because it's too much work for a human.) -- Usenet(n): AT&T scheme to earn revenue from otherwise-unused Henry Spencer @ U of Toronto Zoology late-night phone capacity. {allegra,ihnp4,decvax,pyramid}!utzoo!henry
ggs@ulysses.UUCP (Griff Smith) (06/19/86)
[deleted fine, clear comments about the importance of type checking] > Decent high-level languages ... > ... can also optimize the code better -- most hand-written > assembler is not highly optimized, because it's too much work for a human. Most UNIX system hand-written assembly language is suboptimal because the programmers haven't learned the coding idioms and/or don't give a damn. Humans can do a fine job of optimizing assembly language; they are much better at recognizing special case optimizations that are too expensive/unlikely to put in an optimizer. My code, when it worked, was tight and more optimized than I have seen in most compilers. What usually made my assembly code sub-optimal was the need for parameterization: I had to MOV a parameterized zero into a register instead of CLRing it, etc. I will completely support a paraphrase of Henry's quote: most hand-written assembler code is incorrect; finding all the inconsistencies is too much work for a human. I once spent three days finding a "character with a 3 in it" when I intended to declare an "array of 3 characters". Lint would have found it in 30 seconds. > -- > Usenet(n): AT&T scheme to earn > revenue from otherwise-unused Henry Spencer @ U of Toronto Zoology > late-night phone capacity. {allegra,ihnp4,decvax,pyramid}!utzoo!henry Keep that revenue coming, folks. Thank you for using AT&T. -- Griff Smith AT&T (Bell Laboratories), Murray Hill Phone: (201) 582-7736 UUCP: {allegra|ihnp4}!ulysses!ggs Internet: ggs@ulysses.uucp
henry@utzoo.UUCP (Henry Spencer) (06/20/86)
> > Decent high-level languages ... > > ... can also optimize the code better -- most hand-written > > assembler is not highly optimized, because it's too much work for a human. > > Most UNIX system hand-written assembly language is suboptimal because > the programmers haven't learned the coding idioms and/or don't give a > damn. Humans can do a fine job of optimizing assembly language; they > are much better at recognizing special case optimizations that are too > expensive/unlikely to put in an optimizer. My code, when it worked, > was tight and more optimized than I have seen in most compilers... Note that I said "highly" optimized. When I say that, I mean the sort of code where one spends long periods of time re-writing the code to make the code a few words shorter or a few microseconds faster. Note also that I was not talking about "most" compilers -- I was talking about what the language could do, i.e. what a really hot optimizing compiler could do. The very best optimizing compilers are just as good at recognizing special cases and exploiting them as humans, and they are much better at doing the bookkeeping necessary to do this without error. Building such a compiler is a tremendous amount of work, of course, not least because one must teach it about all those obscure special cases. (The Bliss-11 compiler actually looked to see if it could save a word of "immediate" data by using the next instruction's opcode as the data. Few humans go that far!) It also tends to be huge and slow. But once you've got it, it's a much better way of producing really hot code than doing it yourself. I fully agree that human assembler programmers can easily produce rather better code than the mediocre results from many compilers. -- Usenet(n): AT&T scheme to earn revenue from otherwise-unused Henry Spencer @ U of Toronto Zoology late-night phone capacity. {allegra,ihnp4,decvax,pyramid}!utzoo!henry