maceache@fox.nstn.ns.ca (Tim Maceachern) (01/17/91)
This is an idea I had a while ago. I believe that most applications do not need a 32 bit address space, and most computers won't have that much real RAM anyway. Of course there will be those who want to run huge applications in a 32 bit virtual memory, but... Why not have a tagged jump instruction in the 68000 set. It would take the top 4 bits of the address register (or memory value) and use it as an indexed jump into the next 16 memory locations, each of which would be a jump to a subroutine or such. (Convert byte addresses to word if necessary to create the 16-entry jump table.) This type of instruction would be efficient for interpreters where the type of an operand is not known at compile time. The loss of the 4 top bits is not significant in most applications. The variac (whoops) variable would use a 28 bit address.
henry@zoo.toronto.edu (Henry Spencer) (01/17/91)
In article <1991Jan16.210201.7962@nstn.ns.ca> maceache@fox.nstn.ns.ca (Tim Maceachern) writes: >Why not have a tagged jump instruction in the 68000 set. It would take >the top 4 bits of the address register (or memory value) and use it as >an indexed jump into the next 16 memory locations, each of which would >be a jump to a subroutine or such... If I'm not mistaken, you can do this in three instructions already, two if you don't need to make a copy of the "tagged address": a shift and a jump using one of the fancy indexed modes. Given a sexy implementation like the 68040, this may not be any slower than a custom-cooked instruction, and it's more flexible. Actually, it may be better to fetch an address from a table and then do a jump-indirect on that, rather than branching into a jump table, because then you incur only one pipeline break rather than two. This is getting more and more significant. -- If the Space Shuttle was the answer, | Henry Spencer at U of Toronto Zoology what was the question? | henry@zoo.toronto.edu utzoo!henry
mash@mips.COM (John Mashey) (01/18/91)
In article <1991Jan16.210201.7962@nstn.ns.ca> maceache@fox.nstn.ns.ca (Tim Maceachern) writes: >This is an idea I had a while ago. I believe that most applications do >not need a 32 bit address space, and most computers won't have that much >real RAM anyway. Of course there will be those who want to run huge >applications in a 32 bit virtual memory, but... >Why not have a tagged jump instruction in the 68000 set. It would take >the top 4 bits of the address register (or memory value) and use it as .... I don't have any idea how much the specific feature would be worth, but I would raise doubts about the first part of this, at least over time. Here's a quiz: Q1: during what year would you expect somebody to build & ship microprocessor-based systems with 4GB-maximum of physical memory? (And without being lunatic-fringe types) A: looks like 1993, +/- one year. If you graph MIPS & Sun servers (and some other people sometimes build even bigger memories), on a chart with linear-years on hortizontal access, and log-2 in MB on vertical, you see that this is basically a straight line, increasing by factor of 4 every 3 years. This is hardly astonishing, as the stand rule-of-thumb says DRAMs get 4X bigger every 3 years.... Of course, 4GB == 32-bits, although various traditional hacks are certainly possible to extend this somewhat, although pain mounts quickly. Here's another proposed rule of thumb: if you have X bytes of physical memory, important applications will exist that need 4X that amount of virtual memory. Hennessy claims I'm low, that increasing use of file-mapping and object-oriented programming will tend to increase the sparseness of use of virtual memory, but lots of other people agree with the 4X, right now. (COMMENTS? DATA?) -- -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, 930 E. Arques, Sunnyvale, CA 94086
paul@taniwha.UUCP (Paul Campbell) (01/21/91)
In article <windy.664204455@andrej> windy@andrej.informatik.rwth-aachen.de (Andrew John Stuart Miller) writes: >maceache@fox.nstn.ns.ca (Tim Maceachern) writes: > >>This type of instruction would be efficient for interpreters where the >>type of an operand is not known at compile time. The loss of the 4 >>top bits is not significant in most applications. The variac >>(whoops) variable would use a 28 bit address. > >What do you mean? The TYPE of an operand (int, float, char etc.) >or the address to branch to next? He probably means in languages where the type of operands is not known at compile time (ie ones where you can 'store' an int and a string in the same variable). >The Bouroughs 6500 6700 ( and 7700 I think) series used tagging to >determine the type of an operand at run time. This was done in >hardware roughly as below:- > >A word in store looked like this >[3 bit tag] [48 bit data] > >All arithmetic instructions perfromed their operations on a stack. >The program could fish out operands from memory onto the stack, or use >operands already there from solving earlier parts of an expression, >regardless of their type (well almost...) The tag bits would however >also be read in, and would decide at run time (ie when two operands >were about to be operated upon,) if the operands needed conversion to >the same type as the operation in the instruction, and thus which >arithmetic units to use. > >A side effect was that all the various forms of valid addresses also >were tagged, so that these could also be typechecked at run time. >This way the machine was released without "Protected mode" and only a >compiler (ALGOL-68) rather than an assembler for program development. >(B6700 references are harder to get, hence more verbosity...) No - it was (is) an Algol-60 varient - the Bxx00 series machines are NOT a good match for Algol-68 (heap management etc becomes next to impossible to do efficiently - amoung a whole host of other problems). The 6700 family were a good match for their time - memory was much slower (1.5uS) compared with the CPU - the designers could afford to do run-time type checking of operands. My experience was that the lack of a protected-mode (ie system security/integrity protected by the fact that only trusted programs could make code files) didn't help as much as it might - bugs in the Binder (linker) and compilers often brought the system (in our case a 'large' multi-user system) to it's knees - and the whole concept of code files brought in on tapes provided an enourmous security hole. Another major architectural flaw in the 6700 was that it only had 20-bits of addressing (enough for 6Mb) once memory got a lot cheaper the later machines had to address this limitation (I think they implemented some form of bank switching but I'm not as familiar with these machines). All-in-all I look back on the old 6700 with a lot of fondness - for a machine that was the size of a basketball court and took a crew of about 10 programmers and operators (and one full-time resident engineer) to maintain - it probably had about as much CPU power as the MacII that I'm posting this from ....). Paul Campbell -- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P Where do you find a "kinder gentler nation" when you need one these days?
lkaplan@bbn.com (Larry Kaplan) (01/23/91)
In article <45000@mips.mips.COM> mash@mips.COM (John Mashey) writes: >Here's a quiz: Q1: during what year would you expect somebody to build & ship >microprocessor-based systems with 4GB-maximum of physical memory? >(And without being lunatic-fringe types) > >A: looks like 1993, +/- one year. This is off by about two years, unless, of course, you consider us the lunatic-fringe. ;-) BBN ACI currently has a TC2000 assembled and running UNIX that has 2Gbytes of physical memory. This is done with 128 16-Mbyte nodes, each with an MC88100. BBN has all the technology in place to build a TC2000 with close to 256 16-Mbyte nodes as soon as someone orders one. This will yield 4 Gbytes of physical memory minus about 32 to 64 Mbytes. The fact that we don't quite reach a full 4 Gbytes is to leave room for I/O space. >Of course, 4GB == 32-bits, although various traditional hacks are certainly >possible to extend this somewhat, although pain mounts quickly. The pain mounts very quickly as we decide how to handle the 128 Gbytes machines being proposed with off-the-shelf micros. _______________________________________________________________________________ ____ \ / ____ Laurence S. Kaplan | \ 0 / | BBN Advanced Computers lkaplan@bbn.com \____|||____/ 10 Fawcett St. (617) 873-2431 /__/ | \__\ Cambridge, MA 02238