| PLEX86 | ||
Where should the type information be 167
Yes Bob did a great job after the Multics compiler. From an implementation point of view I think the VAX implementation was a bit of a regression, perhaps because of the buttembler orientation of Cutler and crew. The lexer and parser were originally written in PL-I for good reasons, the former implemented as a state machine and the latter as a recusrsive descent parser implented as a table driven interpreter. The VAX implementers decided to rewrite the lexer in buttembler for efficiency reasons. Now they also built a full flow analyser, which when applied to the lexer would have probably been nearly as good as the hand-coded buttembler, so why? Now the tables were described in a specially constructed language which generated byte codes used to run the interpreter implemented as a set of canonical actions driven by a computed goto. One of the many things that I added was tooling to make the compiler highly extensible. There were many inter-connected tables that made it difficult to, e.g. add new keywords, not that this should (unlike IBM) be undertaken lightly. Thus tools to generate the tables, extending the table building language, TBL, to give it greater expressive power facilitated the process. TBL is also used for sematic analysis and code generation. The latter is interesting because when it was ported to Alpha Tru64 we used Jack Davidson's VPO which used an abstract C machine model and register transfer lists, so what had been a traditional code generation phase was now used to create the RTL's for vpo, which was an interesting excercise since C doesn't know about lexical inheritance in scopes. Where should the type information be 171 Yes, I understand that. TOPS-10 had oodles of customers who did exactly the same thing. The trick is to figure out what can be implemented that is not... I should add that one of the strengths of this design is the separation of the intermediate language, a minimalistic set of n-tuples and the tree-structured hierarchical symbol table, both of which were adequately rich to semantically subsume most common languages and indeed made it very feasible to build a hydra compiler with a single code generator supporting a myriad of languages, as has been adequately demonstrated. One of the nastiest extensions I put in was support for functions without arguments, which IBM permitted without (). So suppose you had declared, say, y and f as entry variable and f didn't have any arguements but returned a value whose type was ENTRY how then did you interpret y = f; Where should the type information be 168 Peter, et al, Not really. There is a reasonable precedence that ALL pre-C languages... Where should the type information be 169 Herman Rubin operators, Herman: I have been foollowing your comments on programming language on the internet for over ten years now. It is obvious that you have...
|
||||
Where should the type information be 168 Alt Folklore Computers from Newsgroups The #1 Usenet Provider on the Internet
|
||||