jallen@eeserv1.ic.sunysb.edu (Joseph Allen) (04/20/91)
How's this for a risc processor: No integer instructions at all. Addresses
would be floating point too, but automatically INTed when presented to the
address lines (or maybe normalized floating point numbers themselves could be
used as addresses...). There would be one floating point number per integer
address or 4 or 8 bytes per address (load byte at location 123.75). When
bytes are loaded/stored they're also converted to/from floating point while
they're in the registers.
The math people would love it :-)
Oh, plus many peripherals could use the floating point directly: forget about
4G colors, have 4G colors with logmerthic intensity... Same deal with sound...
--
#define h 23 /* Height */ /* jallen@ic.sunysb.edu (129.49.12.74) */
#define w 79 /* Width */ /* Amazing */
int i,r,b[]={-w,w,1,-1},d,a[w*h];m(p){a[p]=2;while(d=(p>2*w?!a[p-w-w]?1:0:0)|(
p<w*(h-2)?!a[p+w+w]?2:0:0)|(p%w!=w-2?!a[p+2]?4:0:0)|(p%w!=1?!a[p-2]?8:0:0)){do
i=3&(r=(r*57+1))/d;while(!(d&(1<<i)));a[p+b[i]]=2;m(p+2*b[i]);}}main(){r=time(
0L);m(w+1);for(i=0;i%w?0:printf("\n"),i!=w*h;i++)printf("#\0 "+a[i]);}haynes@felix.ucsc.edu (99700000) (04/21/91)
In article <1991Apr20.063947.12811@sbcs.sunysb.edu> jallen@eeserv1.ic.sunysb.edu (Joseph Allen) writes: > >How's this for a risc processor: No integer instructions at all. Addresses ... Except that it isn't a RISC you have just invented the Burroughs B5000, circa 1960 (and continuing to this day in the Unisys A-series machines). Integers are simply unnormalized floating-point numbers with zero exponents. No type conversions, except there is an integerize instruction used before storing values that are declared to be int-s.
paul@taniwha.UUCP (Paul Campbell) (04/21/91)
In article <1991Apr20.063947.12811@sbcs.sunysb.edu> jallen@eeserv1.ic.sunysb.edu (Joseph Allen) writes: > >How's this for a risc processor: No integer instructions at all. Addresses >would be floating point too, but automatically INTed when presented to the >address lines (or maybe normalized floating point numbers themselves could be >used as addresses...). There would be one floating point number per integer >address or 4 or 8 bytes per address (load byte at location 123.75). When >bytes are loaded/stored they're also converted to/from floating point while >they're in the registers. Sounds like a B6700 et al. all numbers are FP, the FP representations are chosen such that a number with a 0 exponent happens to be an integer with the MSB bits == 0. (Of course they use sign/magnatude rather than 2's complement so they can get away with it ...) Paul -- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P There once was a landlord from Berkeley,Whose apartments were rundown and dirty He decided to run, For the rent-board, and won! Now his tenants are homeless and hurting.
dik@cwi.nl (Dik T. Winter) (04/21/91)
In article <14766@darkstar.ucsc.edu> haynes@felix.ucsc.edu (99700000) writes: > > In article <1991Apr20.063947.12811@sbcs.sunysb.edu> jallen@eeserv1.ic.sunysb.edu (Joseph Allen) writes: > > > >How's this for a risc processor: No integer instructions at all. Addresses > ... > Except that it isn't a RISC you have just invented the Burroughs B5000, > circa 1960 (and continuing to this day in the Unisys A-series machines). > Integers are simply unnormalized floating-point numbers with zero exponents. > No type conversions, except there is an integerize instruction used > before storing values that are declared to be int-s. More like the Electrologica X8 of the same vintage. Integers are simply normalized floating-point numbers. On this machine normalization was not as is currently seen, but normalization involved choosing the exponent with minimal absolute value that would not lose precision. -- dik t. winter, cwi, amsterdam, nederland dik@cwi.nl
mmm@cup.portal.com (Mark Robert Thorson) (04/22/91)
How about addressing memory using addresses similar to the Dewey decimal system? This numbering system allows you to insert an arbitrary number of entries in any arbitrary place, without disturbing the rest of the numbering system. E.g. if you want to put something between 11.44.008 and 11.44.009, you can just create a new address 11.44.008.01. The Xanadu hypertext project is using a similar number system. This feature would allow you to insert into a list without having any links. No pointers ever have to be moved.
mash@mips.com (John Mashey) (04/22/91)
In article <41518@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) writes: >How about addressing memory using addresses similar to the Dewey decimal >system? This numbering system allows you to insert an arbitrary number I'd be interested to hear if anyone has ever thought of any way to implement such a thing that has a chance of reasonable implementation cost in hardware? (I haven't...) -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700 USPS: MIPS Computer Systems MS 1/05, 930 E. Arques, Sunnyvale, CA 94088-3650
kym@bingvaxu.cc.binghamton.edu (R. Kym Horsell) (04/22/91)
In article <2512@spim.mips.COM> mash@mips.com (John Mashey) writes: >In article <41518@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) writes: >>How about addressing memory using addresses similar to the Dewey decimal >>system? This numbering system allows you to insert an arbitrary number > >I'd be interested to hear if anyone has ever thought of any way to >implement such a thing that has a chance of reasonable implementation >cost in hardware? (I haven't...) Apart from CAM's you mean? ;^) -kym
jonah@dgp.toronto.edu (Jeff Lee) (04/22/91)
In article <41518@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) writes: >How about addressing memory using addresses similar to the Dewey decimal >system? This numbering system allows you to insert an arbitrary number Sounds like the "tumbler" numbering system from Ted Nelson's "Xanadu" hypertext system. There was a Byte article on this a few years back, but I can't find the reference right now. Jeff Lee -- jonah@cs.toronto.edu || utai!jonah
rbw00@ccc.amdahl.com ( 213 Richard Wilmot) (04/23/91)
In article <41518@cup.portal.com> mmm@cup.portal.com (Mark Robert Thorson) writes: >How about addressing memory using addresses similar to the Dewey decimal >system? This numbering system allows you to insert an arbitrary number >of entries in any arbitrary place, without disturbing the rest of the >numbering system. E.g. if you want to put something between 11.44.008 >and 11.44.009, you can just create a new address 11.44.008.01. The >Xanadu hypertext project is using a similar number system. > >This feature would allow you to insert into a list without having any links. >No pointers ever have to be moved. I proposed such a system at a symposium on high performance transaction systems in 1985 (or was it 1987?) for quickly doing large volumes of transactions. There were some pretty knowledgeable experts there on both transaction systems and computer architecture but that was the beginningg of the RISC phase so either it was a dumb idea, or it was swamped by RISC religion, or they didn't understand what I was trying to do. I still like the idea and, with larger numbers of transistors becoming available it may get another chance. It solved several problems in a transaction system: o The addressing in memory could be by hashing (with hardware) while that on disk might be organized in a B*-Tree. The slower outboard data structuring could then be easily offloaded to another processor (parallelism). o The addressing in caches is already by hashing so all we need do is use the right bits out of the generated address for that hashing so as to keep collisions and false sharing low. o Locking seems to be a necessary database/transaction operation. It too could be done in parallel by another engine and perhaps more efficiently. Present systems seem to use upwards of 500-1,500 instructions to lock an object (row, page, table). B-Trees are often worse because under updates the locks must propagate up the tree as high as higher keys must be changed in the tree. Locking can proceed in parallel so long as no changes are committed before we are assured that this transaction got the lock and also could have gotten the lock at the time a data item is fetched from memory. o Journalling/logging is also required in most transaction systems and this too could be done in parallel. o Most helpful, perhaps, is that between any two existing objects we can now squeeze (with fractional addressing) as many new objects as we wish. Addresses will get longer but the part used for cache addressing will not. Then, unlike B-Trees, we can stash new objects without consulting the existing structure. The basic principle is that addresses can (and are sometimes) be used for many different purposes/emphases and with the right, flexible addressing scheme we can use the same addresses for these different purposes at the same time in parallel. -- Dick Wilmot | I declaim that Amdahl might disclaim any of my claims. (408) 746-6108