The reason is the effort it takes...... Ask anybody who actually made a CPU ( I myself did a 12 bit TTL based, single address single accumulator machine). The real effort is actually building and debugging the unit. There is only so much time you have.... Much too big to actually build in TTL. In 1974 Elektor magazine started a series of DIY articles that described an extensible ( 12 bit or 16 bit width ) three address, clockless computer. TTL based, with a shiftregister based memory. (6 or 8 512x2 shiftregisters .) An expensive extra wasa 2102 based RAM. The machine did hardware multiply and divide + Instructions were build into the address map .i,e, address XX is the adder, adress yy is a shift and so on.. The start of this series actually predates the Mark8 computer ! Jos Dreesen

Chuck Guzis wrote: That is interesting reading. Are there any of the large 48 bit processors still around? Also TTL and memory is easy to use in 4 bit sizes, a odd size like 18 bits is not so easy to work with.

Genuine parity memory does, indeed, store 9 bits, and you can use it as 9 bit wide RAM. Certainly some of the old 30 pin SIMMs were genuinely 9 bits wide. There was a hrrible thing called fake parity memory. It stored 8 bits and calaculted the parity bit on a read (ignored the incoming parity bit on a write) to keep the memory controller happy. Of course you can't store 9 bits in that type of device. -tony

Yeah, ad I can store 16 bits per location if the high byte is the same as the low byte :-) -tony

Yeah, I've got a reprint of the data sheet in the back of the lab manual for TAoE. More seriously, I have a machine with 16K * 48bit words of memory that can be written under program control, but which can't be read back by said program. This memory has nothing to do with any peripheral device..... -tony

Of course. The processor can write to the control store, it can execute the control store's contents as microinstructions, but it can't read it back as 48 bit words. Of course at the hwardware level the control store is being read when the instructions are executed, the RAMs do have conventional data outputs, etc. I should have made it more difficult by specifying I had a 24 bit machine wit said 16K*48 bit memory. Firstly some people would probably have assumed that there was significance in the fact that the memory width was twice the word size (there isn't, all classic-PERQs have 48 bit wide microcode), and secondly, most PERQs are 20 bit machines, the 24 bit one is moderately uncommon (to put it mildly) -tony

On 11/3/2005 at 5:19 PM Nico de Jong wrote: I had only a short time on a PB250. Compared to other small systems of the time, such as the IBM 1620, it wasn't all that slow. But you could corrupt memory by banging on the side of the machine--those magnetostrictive delay lines were very sensitive to mechanical shock. Cheers, Chuck

So that is 3000 separate components that need to be handled. A 100 TTL packages is probably easier to handle. But yes, a computer without IC's has the higher geek factor. No, but I suspect that for most classes of DIY TTL computers it is actually more complex to make a bitserial machine than a 8 or 12 bit parallel machine. None of the publicised DIY machines is bitserial... I still have a couple of 74hc181. One of these days.... Jos

On 11/11/2005 at 4:14 PM woodelf wrote: You can't get much cheaper than plain scavenging from old boards. Get your torch out! Ebay occasionally has large wirewrap prototyping boards up for auction. That might be just the ticket.eg., http://cgi.ebay.com/AUGAT-72-Pin-Gold-Wire-Wrap-Card-Breadboard_W0QQitemZ756 2252605QQcategoryZ4660QQrdZ1QQcmdZViewItem Cheers, Chuck

On 11/3/2005 at 9:49 AM Paul Koning wrote: ...or one could use a MIPS chip... To me, the genius (and unrecognized at the time) of the 6600 architecture was Cray's discarding the idea of a "condition code" in the IBM sense, wherein the state of a result is actually divorced from the result itself. The 6600 had no compare instruction, nor condition codes. To compare registers X1 and X2 and branch on the result, one would subtract them and test (via branch) the contents of the result register. Three addresses and no condition codes gave a huge amount of flexibility to placement of instructions in the stream. The 15-bit instruction length for the bulk of instructions didn't hurt either. I recall spending many hours hand-timing loops for the 6600 to get to that magic goal of getting one issue per cycle--and even better if the loop could be fully contained in the "stack" (a 10-word local instruction cache). But I don't have rose-colored glasses either. The "call" (return jump) instruction implementation was an abomination because it actually stored the return address as a jump instruction in program memory, rather than putting it in a register. There was no simple way to save all registers (the actual code to do so was a marvel of arcane coding). There was no PC-relative addressing for jumps. I still wonder about the utilitiy of the "count the 1's" instruction. I could go on... I know this seems ridiculous with today's fast CPUs and the amount of bloatware around, but getting tight code was a mark of pride back in those days. I miss that. Cheers, Chuck

On 11/3/2005 at 4:31 PM a.carlini at ntlworld.com wrote: ...and then there are the machines whose designers freely gave in to such requests. The CDC Star-100 is one such. You need an instruction, you've got it. BCD arithmetic (to 65K digits), masked byte key searches, approximate compare instructions, etc. etc., they were all there. Very few people knew the entire instruction set (there were modifier bits for many instructions and the effects of those could range from subtle to downright bizarre). One of the big changes in the 100C from the original 100 was the reduction in size of the instruction set--I know of no other machine where later models actually de-implemented on a wholesale basis whole classes of instructions. The other improvement was the incorporation of a scalar arithmetic unit, so that scalar operations weren't effectively executed as 1-element vectors. Cheers, Chuck

der Mouse wrote: Now, now. If you ask a hundred different TLAs what they most need added to the ISA to best help them infringe people's liberties you'll get one hundred different answers :-) I think the original context (from memory, I cannot find the talk on the web right now) was folks asking for "favourite instruction" to be added in P4. The answer was along the lines of "OK, but the increased complexity will affect the projected yield by %X which will increase costs by $GIGABUX so you need to guarantee to purchase $GIGABUX worth of processors for the first N years". Folks then learn to make do. Seriously, if you need pop(N) or whatever, you can implement it today and in a year (or two) from now you'll be running as fast as you thought you would have been with pop(N). I suppose now that clock speed acceleration is declining, that may no longer be true, but multiple cores should offset that (once we figure out how to use them). Or maybe all these TLAs are now leaning on the GPU manufacturers and that's why we are beginning to see these APIs for ATI and NVIDIA cards so that they can help out with those physics simulations ... Antonio -- Antonio carlini arcarlini at iee.org

der Mouse wrote: This was Intel, so even the NSA/CIA/FBI/EFF all put together are not going to amount to anything more than noise compared to the number of CPUs that Microsoft can help ship. Adding features to something as crufty as ix86 (much of the talk seemed to be about bending over backwards - while blindfolded - to try and keep up some semblance of backwards compatibility) has a dollar, time (to market) and performance cost. Saving the world comes a distant second to keeping ahead of AMD! Other things not to ask for: "Can we have instruction X, and keep it secret: it'll be our competitive advantage" Apparently, yes :-) speed. You aren't willing to pay the costs of having your pet instructions added to ix86 either, I'll wager! Actually I think the speaker's point was mostly that adding instruction X almost never lead to the supposed performance benefits, especially given the complex pipelined nature of the processor. To say nothing of the work required to get the instruction properly supported (and optimised etc.) by the required compiler(s). I presume that the guy knew what he was talking about as he'd managed to get P3 (or P4, whatever) out the door and managed his processor managed to survive in a world where RISC was supposed to be performance king. Most importantly of all, he'd managed to avoid being mired in the Itanium fiasco, so I was willing to cut him a fair amount of slack. Antonio -- Antonio carlini arcarlini at iee.org

Chuck> On 11/3/2005 at 9:49 AM Paul Koning wrote: Chuck> ...or one could use a MIPS chip... Chuck> To me, the genius (and unrecognized at the time) of the 6600 Chuck> architecture was Cray's discarding the idea of a "condition Chuck> code" in the IBM sense, wherein the state of a result is Chuck> actually divorced from the result itself. That's useful indeed, though there were plenty of other machines back then where this was true. I believe the more significant innovations were the extensive parallelism and the quantity of registers. Chuck> But I don't have rose-colored glasses either. The "call" Chuck> (return jump) instruction implementation was an abomination Chuck> because it actually stored the return address as a jump Chuck> instruction in program memory, rather than putting it in a Chuck> register. ... True. Again, something that was conventional back then. Chuck> I still wonder about Chuck> the utilitiy of the "count the 1's" instruction. The rumor has it that the NSA asked for it. Certainly that makes sense. It was also used extensively in the PLATO system. If you want to do fuzzy matches (i.e., accept misspellings for words), a nice way to do that is to encode the words in a clever way, XOR the intended word with the supplied one, bitcount the difference, and accept it if the number of bits that differ is less than N. Chuck> I know this seems ridiculous with today's fast CPUs and the Chuck> amount of bloatware around, but getting tight code was a mark Chuck> of pride back in those days. Sure was. 600 timesharing terminals on a pair of 10 MHz processors is pretty slick. (Come to think of it, over 9000 timesharing terminals on a single Alpha-based descendant of that system is mighty impressive, too.) paul

Chuck> Wasn't the standard Plato hookup 2000 baud? My last exposure Chuck> to the terminals was back when they still had plasma screens. Chuck> Very cool, those--I wonder if there are any still around. 1200 baud, but the output encoding was such that the best case text plotting speed was 180 characters per second. Yes, there are still some working PLATO plasma panel terminals around. And for that matter there are still working PLATO systems around (one "real" and one running on an emulator). paul

J> Do you remember the CDC song? "I/O, I/O, it's off to disk we go! J> Put CIO in RA+1, I/O, I/O..." Eek. It's amazing to me that still to this day lots of people do not know that circular buffers are the way to do inter-processor communication without interlocking. For example, RTLinux did (perhaps still does) have to disable interrupts for its IPC, because it uses queue structures that aren't interrupt-safe, rather than CIO style buffers that are. In systems like that, the penalty for not knowing the right technology is pretty steep. paul

Chuck> On 11/3/2005 at 12:03 PM J.C. Wren wrote: Chuck> Heck, I can probably remember most of the PPU overlay names Chuck> and what they did. Ok, let's test that. 1LT? :-) (I've been doing battle with that particular one recently...) Chuck> For a time, I worked on a transaction system on the Cybers, Chuck> where system calls were done exclusively with XJ instructions Chuck> and not RA+1 stores. Made much more sense when your system Chuck> was CMTR based--and on this particular system (swaps were done Chuck> to ECS), exactly where RA was for any given job could change Chuck> very rapidly. But then, 7000 SCOPE did much the same thing, Chuck> didn't it? Before my time... I worked on PLATO when it ran on 6000 series NOS. paul