| PLEX86 | ||
Where should the type information be 337
I agree with you that many of the problems buttociated with computers and debugging might be eliminated if data was either described by descriptors or typed with tags, or both. I wrote a paper in 1973: E.A. Feustel, "On the Advantages of Tagged Architectures", I.E.E.E. Transactions on Computers, Vol. 22, pp. 644-652(Jul 73).
In which I advanced a number of arguments for doing this and for providing "Self-Describing Data". Note that XML seems to have taken up this idea for data to be transferred between machines.
Where should the type information be 338 fs (future system) was an effort that was targeted at all sorts of complex hardware descriptors ... there was some analysis that the worst case could have five levels of indirection (in... Unfortunately, life moved toward the C language which has a basic notion in conflict with typing: an address is just a number and you can add an integer to it and come up with another address which you can use. This notion makes it quite difficult to implement on machines that know the difference between addresses and numbers. (See Iliffe's The Basic Language Machine book.)
If further as he describes, addresses represent either locations to which you can transfer control or regions of storage that can be indexed, you have gone a long way to prevent buffer overflow and to prevent "hostile" takeover of a rogue program. There are also significant possibilities for the use of parallelism and multiple functional units, a'la the CDC and Cray machines and even restructurable computers:
S.S. Reddi and E.A. Feustel, "On Restructurable Computer Architectures", I.E.E.E. Transactions on Computers, Vol. 27, pp.1-20(1978). A Best Transactions Paper Prize from the Computer Society for 1978.
It becomes interesting for machines to do "For All Elements" mathematics using as much parallelism as they can muster. And if they know what to do with "infinity", NaNs, etc., so much the better.
As has been pointed out, at the time, memory and peripheral storage were perhaps the most expensive parts of computer systems, so there was considerable economic justification for not making the change -- witness the ICL 1900 instead of the practical implementation of Iliffe's design. Logic was also limited. As I recall (perhaps incorrectly) someone said that an IBM 360-50 was implemented with about 50K gates. And it was not fun to build machines from "minute-scale-integration" cmos or ecl! Think what could be done with today's VLSI!
Now, I think that the big problem is operating systems. For better or for worse, Unix-Linux and programs written in C or C-like derivatives with a C-style (flat data) memory model have taken over and it is unlikely they will be supplanted any time soon.
For a new architecture to take hold quickly, you need to have an "off the shelf" OS and a large stock of programs to run on them -- hence the success of SPARC, MIPS, and Power PC to name a few (let alone the Intel x86). It is so much "easier" to evolve than to have a revolution to data flow or something "more interesting" even if there can be significantly better security, error detection, hardware optimization, etc.
As to languages that could benefit from machine types, take LISP, Icon, and APL to name a few and data as mentioned XML.
Ed Feustel Where should the type information be 341 Ah! I was peripherally involved in that POSC effort too, and a good friend of mine was in the thick of things. Quite interesting stuff, and good people were involved. As you mention...
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==---- ---= East-West-Coast Server Farms - Total Privacy via Encryption =---
|
||||
Where should the type information be 338 Alt Folklore Computers from Newsgroups The #1 Usenet Provider on the Internet
|
||||