:
John Larkin
No, d*****ad, I agreed about what the original term is, not what it meant. It meant reduced *complexity*. A trade of complexity for speed. Thus all loads/stores decoupled from the ALU.
You *are* an idiot. I simply stated the point when you made it clear.
If ADD and SUB aren't different, then to be consistent, neither are ADD and AND. They're both the same with a different parameter to the ALU. They're generally considered different though. Register reference, Memory reference, Indirection are much different, IMO, since it involves a completely different area of the processor.
Reduced in complexity. There are still just as many instructions.
It's all about how you count instructions (a rather silly thing to do).
The original plan (before the project was started) was for 250,000 with the number going up quickly after. Those are the facts.
y
I forget what brand recorder I was using. I don't think it had a label that was very large marking what it was. It was a portable that I had first bought to play music on. It was not a really cheap one.
I remember it as 77. The code I had was for the ZX80.
It was good enough for games etc.
On the integer basic, I had sin() and cos() that used 32758 as a half rotation. I wrote a Startrek game that had space as a sphero-toroid. Working out where the long range sensors would show stuff turned out to need the math library I had written for other things.
Yes it does work better. I have often seen the error an error in programs where they lose the resolution on the input data by using floats.
There is an parallel loaded shift register. Every time a NOP instruction cycle causes the load of a character, it first puts the character into a latch and then uses that to address the PROM to get the bits that go into the shift register. The interrupt vector register brought out on the bus during a memory refresh. It was used to make the upper bits of the address so that the table location was not fixed.
When I did bit graphics, I took advantage of this. I made my own "character generator" that was in fact the graphic display I wanted and then filled the character space with simply 0,1,2,3... So that the bytes would be addressed.
nd
as
wIf you fetch more bytes per fetch operation than an instruction is long, you could have an extra trip to RAM here and there, but generally, I agree with you.
If you look at some DSP chips, they have more than just the two busses of the Harvard machine.
Therein lies the rub. In particular X86 is a variable length instruction set from one byte to over 8 bytes without the new(ish)
64-bit modes.
If you were around to read the literature of the time, the instruction sets were also regularized. And instructions were also all the same length.
Not really key. The original main objective was a short pipeline and single cycle execution once the operands were available. This is what rules out RMW opcodes.
Long time maybe. But I'm comparing how much nice peripheral stuff is now packed in as normal. I.e an 1985 meter would have required design- in of not just the Z80 but lots of glue logic+RAM+ROM+ADCs+timers
+alphameric display+hefty power supply etc. Code recycling has never been an issue, as I only design hardware and each new job invariably has to start with a blank sheet. Most of the stuff I've done has been in assembler and obsolescence seems not a prob with the Z80s and PICs. I've been coming across this 'C is portable' mantra, for the past 25 years. Yet when looked into find C no more or less portable than any other language. The Basics I've used, port with ease. Problem is the uni's have forced C to the forefront, leaving Basic with fewer supporters, hence portability is now limited. But, that's a problem for career programmers to worry over, not me!. . Yep. the AVRs are like a PIC on speed, with a toke of coke thrown in for clarity ;). Has 3 brown out fuse settings and 2 internal clock rates. Used PICs 100% until last year, when A. Freemont here convinced me Atmel was the way to go. Never looked back. A Mega88 at 20MHz, runs each instruction in 50nS, has a hardware 8x8, will do a signed longxlong in 3.75uS, NO sodding paging or banking or 256 byte breaks or movlw. Assembler is a breeze. From an equipment POV, AVR seems about 10x more powerful than PIC.
I'll accept that refinement, though obviously load/store was never single cycle. It also forces a separation in load/store and ALU ops, not just RMW. Again, the point was reduced *complexity* of instructions such that each could be as fast as possible.
??? You must be mistaken; I've always been a PIC advocate. Now I'm in love with ARM.
The variable length in the X86 is mostly the result of the extra bytes specifying details about what is to be done. Consider the ADD immediate to memory or register as an example.
The upper 6 bits of the first byte gives you what is being done. The two lower give you the width of the ALU action and the immediate operand.
The later bytes give the addressing details. This is how it is for pretty much all of the longer ones.
I was around and did read about it. This is why I pointed out that the breaking apart of the load/store and the ALU operations was not the only thing under consideration. Early in the RISC development they went back to the fixed instruction length. The PDP-8 was fixed instruction length and was created before instruction sets got complex enough to need reducing.
That really was a sub goal to get to the goal of getting greater speed by having more efficient use of transistors. Transistors were not considered free so any that were used for an ASCII adjust for divide couldn't be used for something else that really mattered.
On a sunny day (Sun, 1 Feb 2009 12:44:40 -0800 (PST)) it happened snipped-for-privacy@jjdesigns.fsnet.co.uk wrote in :
Was not Atmel for sale or sometng?
It was a bidirectional shift register (it was also used for save/load to/from cassette). But for video, it was used PISO ;)
Yes, Microchip (PIC) tried to buy them. The GFC stepped in and ruined the deal though, not to mention that Atmel put up a fight.
Dave.
[Blush]. My sincere apologies Anthony!. I'm totally intrigued now as to who the hell made the AVR case. I'll have to check back. Apologies again.
No apologies needed, I just doubt that it was me that persuaded you to go with the AVR. OTOH, I would recommend them to those that want to program in C. The 8-bit PICs are just not cut out to do C very efficiently.
Then there is also the base register prefixes, with up to 3 prefixes possible. Nor were the address/register/mode bitfield positions and widths 100% consistent, they could even appear in different octets (bytes).
Do you also remember such things as writable control stores?
Close enough.
apparently it was not for sale, although microchip wants to buy it.
:
Lets also not forget the REP prefixes. They are a strange duck in that they work a lot like a decrement and conditional jump was added after the string instruction.
[...]Yes.
For those who don't know, things like the IBM 360 had a control store that had to be loaded with the micro code before the thing would have its defined instruction set.
I am also old enough to have worked on the design of bit slice computers, printed out my listings on a teletype, input my code on paper tape, and write programs on punch cards that were sent away to the computer.
[...]
te:
eWhich IBM 360? "Things like the IBM 360" is a meaningless=20 statement, when talking about hardware (implementation). "IBM=20
360" signifies an architecture not an implementation. Each model's=20 implementation was quite different from the others in the series. =20
Brings fond memories. Who sells those chips these days. Like 808* and Z8*. Last time I checked distributor didn't even reqogbize those chips.
Someday I hopefully have time to play with those chips.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.