Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!tut.cis.ohio-state.edu!ucbvax!mtxinu!taniwha!paul From: paul@taniwha.UUCP (Paul Campbell) Newsgroups: comp.arch Subject: Re: 68xxx memory addressing Keywords: tag 68000 Message-ID: <755@taniwha.UUCP> Date: 21 Jan 91 01:20:45 GMT References: <1991Jan16.210201.7962@nstn.ns.ca> Reply-To: paul@taniwha.UUCP (Paul Campbell) Distribution: comp Organization: Taniwha Systems Design, Oakland Lines: 65 In article 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?