home *** CD-ROM | disk | FTP | other *** search
- ************
- Topic 20 Fri Nov 25, 1994
- H.HERMAN1 (Forwarded)
- Sub: Pentium woes...
-
- No doubt that by now you have all heard of the infamous bug to be found in
- each and every Intel Pentium chip ( *Intel Inside* ), and by implication,
- *all computers* bearing the Pentium label.
- 74 message(s) total.
- ************
- ------------
- Category 2, Topic 20
- Message 1 Fri Nov 25, 1994
- H.HERMAN1 (Forwarded)
-
- No doubt that by now you have all heard of the infamous bug to be found in
- each and every Intel Pentium chip ( *Intel Inside* ), and by implication,
- *all computers* bearing the Pentium label.
-
- Intel claims the "bug" can be expected to appear, for the "average" user,
- only once in every 27 years. Therefore, they claim it is not serious, and
- will replace the errant CPU only for those who can "prove" they are running
- mathematically critical applications.
-
- Talk about unabashed stonewalling......
-
- or...
-
- Hey! This does not sound all that serious then, right?
-
- Well, yes and no.....
-
- What if you just happen to be the patient undergoing a heart bypass? Would
- you feel comfortable knowing that YOUR surgeon will be relying on imaging
- based on the Pentium? ha!
-
- So? How obscure is this bug which will appear only once in every 27 years?
-
- OK! Take out your Pentium folks!
-
- What? You don't have one?
-
- Then rush down to your local Pentium retailer/dealer, and put a computer to
- the test!
-
- A test?
-
- Yup! One manifestation of the BUG will ALWAYS appear if you calculate:
-
- x=4195835
- y=3145727
- z=x-(x/y)*y
-
- As any C64 and C128 owner will tell you, Z=0. Basic7 returns a zero. Most
- applications will also return a zero. In the case of roundoff errors, a
- number no larger than 9.3e-10 is returned.
-
- In fact, most all computers return a ZERO.
-
- So, what about a computer adorned with a Pentium CPU?
-
- It says Z=256. omigawd..........
-
- ----------
- Hey folks!
-
- Hang onto your C64's and C128's!!
-
- They are more accurate than the Pentium.
-
- Howie
- ------------
- Category 2, Topic 20
- Message 2 Fri Nov 25, 1994
- THE.OUTLAW (Forwarded)
-
- I'll bet you had a good time at the computer store, Howie! hehehe
- ------------
- Category 2, Topic 20
- Message 3 Fri Nov 25, 1994
- H.STEVENS5 [HaroldOH] (Forwarded)
-
- You realize Howie that you have finally found a way to allow a commie user to
- become smug toward a Pentium owner. I can't wait to use this and tell them
- that my C-64 is smarter than their Pentium. :)
-
- --Harold
- ------------
- Category 2, Topic 20
- Message 4 Fri Nov 25, 1994
- SAUVIN [Ben] (Forwarded)
-
- The 6502 (actually, the 6510) that drove my original C64 had a flaw, probably
- well-known in this RT, where the ML instructions
-
- lda whereat,x
-
- would load the accumulator with a garbage byte. Fortunately, that bug was well
- known enough that we didn't (and don't) get stung by it with commercial
- software, and it was (is) absent in the C128's 8502.
-
- When I was trying to develop a routine for graphing (plotting) complex
- functions on a C128's screen, it blew up because of a bug in the graphics
- commands that I didn't know about - the program was eventually completed by
- using combinations of the less "advanced" commands, making it much slower than
- should have been the case. I do NOT recall what the commands were, except that
- negative vectors were a problem.
-
- Does anybody even REMEMBER the return rates for early Commodore machines? My
- first VIC-20 was also my LAST one, for which I am thankful. However, I went
- through three or four C64's before finally having one that could stay alive
- for more than a few hours. The 128 on the desk is my second, and the 1581 next
- to it is the third I've exchanged for, and it STILL doesn't work reliably.
-
- Telling a Pentium owner his machine is inferior because of some bug that might
- pop up once every 27 years is sorta like throwing stones from our glass house
- living rooms.
-
- (Meanwhile, the keyboard on the C128 is dead, or I'd still be using it. When I
- have $$ again, I'll have a another - NO machine has ever proven a more benign
- place to experiment with interrupt-driven programming, you simply CANNOT kill
- a 128 with bad code)
- ------------
- Category 2, Topic 20
- Message 5 Sun Nov 27, 1994
- S.GOLDSMITH2 [Iron.Man] (Forwarded)
-
- >The 6502 (actually, the 6510) that drove my original C64 had a flaw,
- >probably well-known in this RT, where the ML instructions
-
- > lda whereat,x
-
- >would load the accumulator with a garbage byte. Fortunately, that bug was
- >well known enough that we didn't (and don't) get stung by it with
- >commercial software, and it was (is) absent in the C128's 8502.
-
- I thought it was LDA ($FE),Y if $FE $FF pointed to $02FE and Y caused it
- to go past a 256 byte page boundry. It's been a while since I've written
- 6502, but it was something like that...
-
- SG :)
-
- ------------
- Category 2, Topic 20
- Message 6 Sun Nov 27, 1994
- BEN.GELAMP [Ben] (Forwarded)
-
- Iron.Man:
-
- I don't clearly remember the details of the bug you name, but I remember it
- now. There WAS something about a page boundary wraparound problem that never
- DID get fixed, that I know of. If memory serves, the construction
-
- lda ($fb),y
-
- where $fb is $00, $fc is $6e and .Y is $ff, the CPU would load the LSB of a
- pointer from $6eff and the MSB from $6e00, which is hardly what would have
- been expected. Or am I confusing this operation with another? All I DO
- remember is that the .Y register would not cross a page boundary in this
- construction. The reason I don't really remember it is because I do remember
- reading about this bug before really trying to use the instruction, so I was
- able to take precautions against it.
-
- The LDA WHEREAT,X problem where .X is 0 really ticked me off to NO end until
- I learned that it WAS a bug (I thought the assembler I paid good money for was
- junk) - I even taught the cat new ways to abuse the English language.
- ------------
- Category 2, Topic 20
- Message 7 Sun Nov 27, 1994
- E.GBELL [e.g.bell] (Forwarded)
-
- BG> The LDA WHEREAT,X problem where .X is 0
-
- I am familiar with the zp bug you mention regarding page boundaries.
- I'm not sure it was a load, though.... but I have never heard of (or
- experienced) an problem with indexing an absolute address with the .x
- register, regardless of the value of .x. What assembler are you now
- sure the problem was not with, and where did you learn that this *was*
- a bug? Do you have an example we can duplicate.
-
- ------------
- Category 2, Topic 20
- Message 8 Sun Nov 27, 1994
- BEN.GELAMP [Ben] (Forwarded)
-
- E.G.Bell..
-
- You won't be able to duplicate the bug if you have a C128, since that
- particular bug didn't survive the trip from the C64's 6510 to the C128's 8502.
-
- There was no "zp" (I assume that to mean zero page) involved here,
- particularly. On a 6502 and a 6510, the construction
-
- lda whereat,x
-
- loads the accumulator with a garbage byte (unpredictable value) when .X is
- zero.
-
- The bug can be repeated with any assembler; I've gotten stung by it on both
- the Commodore Macroassembler (what a kludge!) and the Power Assembler
- (Spinnaker, formerly the Buddy Assembler, well recommended!) as well as
- Micromon and Supermon.
-
- Furthermore, both bugs mentioned in this topic, among others, are documented
- in Raeto Colin West's Programming the C64 (*very* highly recommended).
- ------------
- Category 2, Topic 20
- Message 9 Mon Nov 28, 1994
- E.GBELL [e.g.bell] (Forwarded)
-
- I also have a 64 Ben.... and learned my ML on it as a matter of fact.
- I'm not trying to dispute what you say.... just that I've never seen
- mention of the absolute,x thing you mention. I remember the other one,
- whether it was one of the indirect zp ones or an indirect JMP... even
- gotten bitten by it.
-
- Can you direct me to the section describing this bug in RCWest's book?
- I have it and have long considered it one of the most valuable in my
- library. I've never had problems with that particular instruction,
- regardless of the value of .x. I will take some time tonight and try
- to find mention of the one w/the .x register. I honestly don't remember
- where I saw the zp one, tho I've seen it frequently over the years.
- Do you have a sample of the code that doesn't work? Of course, I guess
- that :
-
- ldx #0
- lda absolute,x
-
- is all it would take, huh? BTW, it is not mentioned under the LDA
- discussion on page 312. On the other hand, I was correct about the
- indirect JMP being the culprit in the other case. On page 310 of Mr.
- West's book he describes it:
-
- 'Note that this instruction has a bug; JMP ($02ff) takes its new address
- from $02ff and $0200,not $0300. That is kind of what I remembered about
- the other thing you were talkng about.
-
- On page 303 of the book, there is an example using the kind of code you
- say is flawed....
-
- ldx #0
- loop lda $0278,x
- sta $0277,x
- inx
- cpx #$c6
- bne loop
-
- Substitute 'whereat' for $0278.... are you sure this is a known bug? The
- book I have by Mr. West is the one for the 64... matter of fact, the
- example under the LDA instruction uses the same kind of code:
-
- ldx #$00
- lda $7000,x
- sta $8000,x
- dex
- bne -9
-
- Of course, if the bug requires that the instruction use a label, then
- perhaps the bug is common across the assemblers you used?
- ------------
- Category 2, Topic 20
- Message 10 Mon Nov 28, 1994
- BEN.GELAMP [Ben] (Forwarded)
-
- Wow.. perhaps it's my MEMORY that's flawed.
-
- If I can find that book again, I'll fish it out.
-
- ------------
- Category 2, Topic 20
- Message 11 Tue Nov 29, 1994
- SAUVIN [Ben] (Forwarded)
-
- It looks like I was totally into left field about the
-
- lda whereat,x
-
- mode of addressing, and I think I found out why. DARN, this is irritating! - I
- started avoiding that addressing mode very early in the learning process
- because of something I must have MISREAD on pages 219-220 of Programming the
- C64.
-
- What could also have confused me is the nature of
-
- lda zp_loc,x
- lda zp_loc,y
-
- where the operation never loads the accumulator with a garbage byte PER SE,
- but CAN load it with an unexpected value if (for example) zp_loc is $fe and x
- (or y) is 2 - the value won't be taken from $0100, but from $0000.
-
- I can find no reference to any bug concerning load or store operations,
- either in RCW's Programming, the Commodore PRG or Mapping the C128 except the
- problem with
-
- jmp ($567f)
-
- bug, which reads an LSB from $56ff, but an MSB from $5600 - and yes, this one
- has stung me, too.
-
- It's also possible the problem I read about was indeed with an assembler,
- although I doubt it. I remember *something* about it being repeatable no
- matter what translator I used.
-
- :sigh:
-
- There WAS somewhere, somehow, something that was a bug in the 6502 that
- wasn't in the 8502 - I clearly remember reading SOMETHING about it - but I
- suddenly find myself believing I know a LOT less about those chips than I used
- to THINK I knew. It's just been too long since I've seriously done anything
- with those machines.
-
- This whole thread actually started by mentioning the Pentium's less than
- ideal handling of floating point math (I believe but don't KNOW that the
- problem is with the FDIV instruction, floating point divide) - somebody tried
- to suggest that Pentium machines were relatively brain-dead because of that
- fact.
-
- It's irrational that I'd feel personally stung by such a comment, since I
- don't even have ACCESS to a Pentium, or plans to buy one. I was no less
- antagonised when people laughed at my Commodore 128. I don't imagine it's
- necessary to tell anybody here it's more than just a game machine, perfectly
- capable of handling all the major types of software, and that's precisely what
- it DID do for me, for the better part of a decade when people were trying to
- tell me to spend several thousand dollars on IBM hardware that (at the time)
- had only the advantages of speed and size.
-
- I'm hardly innocent of that kind of antagonism, myself. It wasn't terribly
- long ago that one of my favourite cosysops and I had a major row about my
- putting down the Macintosh line of computers - I'd say "Your Mac can't handle
- THIS" or "That kind of software isn't available for your Mac", and so on, and
- so forth, until one day the turnabout exploded in my face with "WILL YOU QUIT
- CUTTING DOWN MY MACINTOSH, YOU SMUG CONDESCENDING !@$#^!!"
-
- It'd never occurred to me that some people take their machines (or even
- IDENTIFY with them) every bit as much as I.. or even MORE.
-
- In the time since, I've learned that Macintosh does indeed have some of the
- same kinds of internal problems with their operating systems as do the current
- crop of IBM machines, legacy code and data structures limitations, for
- example, and have had to consider (yet once again) that each machine has its
- strengths, weaknesses and appropriate applications. What other kinds of
- machines may have this general kind of problem, I cannot say, but on the basis
- of the machines I've dealt with so far, it'd surprise me greatly to learn of
- ANY machine/OS/platform that hasn't had growing pains.
-
- We could go on and on and on about bashing other people's computers on the
- basis of perceived faults. For what gain (I ask as I remember that angry
- cosysop's "voice")? Much of it is history, and most of the remainder is
- actually academic. It is true that Commodore people tend to be extremely loyal
- to their machines.. but ST people tend to like THEIR machines (calling PC's
- kludgy, not without reason), as do also Amiga people, as do users of most
- other brands of current or classic hardware.
-
- That loyalty, to a degree, is a Good Thing. We can't feel good about our
- computering experience(s) unless we feel good about the machines we're working
- with, but our zealotry crosses the line when it blinds us to the advantages
- other machines might offer.
- ------------
- Category 2, Topic 20
- Message 12 Tue Nov 29, 1994
- GEOS-TIM (Forwarded)
-
- I know an interesting fellow that has just about every kind of computer tht
- you could think of: Macs, C64, C128, Pentium,etc. I think he even has a Old
- Tandy. He told me that he uses all of them from time to time, because they
- all do some special things for him, and since he has the luxury of having
- plenty of room for them, he is indulged.
- Bottom line on any computer, or software: It has a job to do. What ever
- computer you have you have a sizable learning curve that has been mastered,
- and you start knowing all the intricate things that your computer and software
- can do and not do. I use GEOS most of the time, and I still learn things from
- and about it. I think that is part of the charm of using them.
- I have a copy of geoShell on my disk shelf. I have booted it up several
- times, and I recognize that it has tons of power in it, but I don't have the
- time to invest in it right now, to learn it thoroughly, so I sort of get it
- out from time to time. Eventually, I'll be using it a lot, but it has to fit
- around my many projects.
- We all have time invested, and we have computer projects sitting there. The
- more we know our computer and software, the better we can get that job done.
- So you're right , Ben. Everyone gets attached to their computer in some way,
- cuz after all, it is sort of like a non human fellow worker. But I can't think
- of any computer "personality" nicer to work with than my Commodore.
- :) -Tim
- ------------
- Category 2, Topic 20
- Message 13 Wed Nov 30, 1994
- H.HERMAN1 (Forwarded)
-
- Ben,
-
- I, for one, can easilly identify with most all of what you said.
-
- It is interesting to observe also how owners of new Pentium computers do too.
-
- While the Pentium is relatively new, the impression I get is that their owners
- are livid with outrage at the way Intel is handling this problem.
-
- I recall when the C128 first arrived, it had the now famous Cap's Q bug, and
- other problems. As I recall it was clear from the outset, thanks to widely
- distributed postings of Fred Bowen, that Commodore would fix this. True to
- its word updated C128 ROM's were made available for a nominal charge.
- Something like $15, if I remember correctly.
-
- This contrasts sharply with how Intel is attempting to stonewall their
- problem, and require "proof" from its customer that he/she requires a properly
- working MPU, before giving a replacement will even be considered.
-
- We all seem to get attached to our electronic toys very quickly. Finding out
- that it is flawed can indeed prove upsetting.
-
- Tim has hit the provebial nail on its head by observing that the factor of
- time and a learning curve for any computer plays an important part in the
- formula.
-
- Howie
- ------------
- Category 2, Topic 20
- Message 14 Wed Nov 30, 1994
- M.RANDALL2 [Maurice] (Forwarded)
-
- I just thought that I might throw in my own thoughts and opinions on the
- JMP(indirect) subject. I won't comment on how this subject got started with
- the deal on the Pentium, but I thought it to be quite funny that the Pentium
- truly does have a nasty bug as such. Plus, I like the fact that I can lay my
- finger on a powered up 6502 without getting burned.
-
- Anyway, the 6502 has been around for a long, long time. Even long before
- Commodore built the first PET computer. And the early 6502's no doubt did have
- some bugs. It was quite an advancement in microprocessors just as the new
- processors of today are. The JMP to an indirect address was designed for
- program designers to place a set of addresses into a table within memory.
- These addresses would then make reference to the desired location where the
- programmer intends to jump to. This table would be in a 'known' location so
- that software could easily alter any of the values within the table and
- therefore cause a program to jump to a different location as desired. Any one
- of these addresses could be referenced as many times as needed anywhere within
- the program. So, to cause several different routines to jump to a specific
- location only requires two bytes to be altered, rather than altering several
- sets of bytes scattered throughout the program.
- The CBM operating system makes use of this feature. There are indirect
- vectors located in memory that point to various routines such as the interrupt
- routines and the loading and saving routines, etc. When the 6502 was first
- designed, it was given three fixed vectors of which the location of them
- cannot be changed. These are the NMI, RES, and IRQ vectors. They were placed
- at the highest locations addressable by the 6502, at $FFFA-$FFFF. This puts
- them out of the way and leaves the rest of the memory map available for
- programming and other uses. The 6502's stack is always addressed at page one
- of memory from $0100- $01FF. This location can be changed through hardware as
- is proven with the 128. But otherwise it is always in the first page. Page
- zero was thought to be an excellent location for indirect vectors. It would be
- easy to remember where they are located and easy to alter. This more than
- likely was the original idea for where to have the JMP(indirect) vectors
- located. They would be contained entirely within one page of memory. The first
- one would be at $00,$01 and the second at $02,$03 and so on (Of course,
- $00,$01 got put to use for other purposes). There was room for 128 vectors
- within this page of memory. If all of them were used, then the 128th would be
- at $FE,$FF. The next page would be the stack. No more room for vectors.
- Now, with a little thinking, and thank goodness for that, the designers of
- the 6502 probably thought that there just might be a need for more than 128
- vectors in some programs. Maybe this feature shouldn't be limited to page
- zero. Let's allow it to be located on any given page in memory. And so it was.
- One little thing was overlooked in the design however. If a table of
- indirect vectors began on an odd address and there were enough in use to cause
- the table to cross over into the next page, a minor problem would occur. The
- zero page thought still existed. The next page of memory was not allowed to be
- accessed in order to fetch the high byte of the destination address. Instead
- the high byte is fetched from the first location of the current page. This
- occurs when the vector begins on the last byte of a page, such as $08FF for
- example. Your program has the second byte (the high byte) of the vector
- sitting at $0900. The 6502 will use the byte at $0800 instead.
- So, is this really a bug? I don't think so. If you understand how the
- operation works, it will never affect your programming. The answer here is to
- always place your indirect vector table either at the start of a page, or
- start it on an even byte. If it begins on an odd byte, you are asking for
- trouble unless you know for sure that it will not extend past the end of a
- page of memory. As long as it begins on an even byte, then you can make the
- table just as large as you need within the confines of memory.
- Internally, within the 6502 itself, what is happening is this: The 6502
- begins by fetching the operation code to begin it's next instruction. It finds
- a $6C there. This is the opcode for the JMP(indirect) operation. Now it knows
- what it needs to do, and this whole operation is going to take up a total of 5
- clock cycles. We have about a million clock cycles to work with every second.
- The 6502 has already used up one cycle. On the next two cycles it gets the
- value contained in the next two locations. It now knows where the vector is
- that contains the address it should jump to. With this info, the 6502 then
- goes and gets the first byte of the vector during the fourth cycle. It then
- adds a 1 to the address where it found the first byte. This now points to the
- second byte of the vector, which it will fetch on the 5th and final cycle of
- this operation. BUT... within the 6502, when it added a 1 to the address of
- the vector, it did not take into account it's own internal carry. It should
- have added the value of the carry to the high byte of the location of the
- vector. Since it did not, it will still look within the same page of memory
- for the second byte of the vector. The carry never gets added internally when
- fetching the indirect vector as it increments it's address pointer to the
- second byte of the vector. This is not the carry flag as we know it, but the
- carry that is within the 6502's own little arithmetic logic unit (ALU).
- Again, I don't see this as a bug, but more like something that a programmer
- should just remember about when writing his software. There are other
- processors with worse problems. Some of the 16 and 32 bit processors require
- that an actual instruction begin on an even byte. This forces you to place
- unused bytes here and there so that the instructions don't begin on an odd
- location. Not too handy. The only time we need to do this with a 6502 would be
- just prior to an indirect vector table. A zero byte or a NOP instruction could
- be placed there if the last instruction would cause the table to begin on an
- odd byte. Sure it's a wasted byte, but it beats spending a week trying to
- debug a program that doesn't work.
- Just as a side note, here's an imaginary scenario on an early 6502 potential
- problem: Imagine it's 1977 and you just bought one of the very first PET
- computers. Shortly afterwards, it develops a problem and you have to take it
- in for repairs. While trying to figure it out, the repair technician replaces
- the 6502 and does some other stuff. It starts working and you are back in
- business. Probably it was the 'other stuff' that fixed it. Well, the 6502 that
- just went into your new computer was one that just happened to be 'lying'
- around the repair facility. Hmmm... Ready? Prior to June of 1976, the 6502's
- did not have a ROR instruction in them. Whoops. Some software just doesn't
- seem to work like it should.
- Isn't this fun.
-
- - Maurice Randall
-
-
- (P.S. Sorry for the length of this message for those that had to scroll
- through it and are not interested in this sort of stuff.)
-
-
-
- ------------
- Category 2, Topic 20
- Message 15 Wed Nov 30, 1994
- GEOS-TIM (Forwarded)
-
- Maurice "Guru of the Programming Mountain"
- It is always a pleasure to read your positive feedback, even if I don't
- understand it all, it still makes sense. May your overlooking of percieved
- 6502 limitations continue unabated. :) -Tim Or should I say, Sweeping away
- perceived 6502 limitations? :)-Tim
- ------------
- Category 2, Topic 20
- Message 16 Wed Nov 30, 1994
- BEN.GELAMP [Ben] (Forwarded)
-
- LOL!
-
- Maurice, anybody who can worry about an "internal carry bit in an ALU" is a
- far, far better computer nerd than I :)
-
- I enjoyed every word of what you wrote - do it again sometime!
-
- Two of the pleasantest discoveries about the Commodore machine were the
- existence of the formal services that you can call with a simple JSR (for
- example, CHROUT ($ffd2) with the character in .A, and the other was the
- existence of the vector table in Page 3 that use the jmp (wherethru)
- construction. It made interrupt-level programming possible, and OOooOOoo, was
- THAT ever fun! I used it to redirect the keyboard handler to something that
- did FUNKY things to my roommate's typing on his 128 :>
-
- I knew the 6502 had been around for a while when that first VIC-20 appeared
- under the Christmas tree, but since 1976!??! Gee.. no WONDER they were so
- sound!
-
- You might be pleasantly surprised to learn (if you didn't already know) that
- the PowerPC instruction set is supposed to be far simpler than the 8086's -
- it's supposed to be as simple (or possibly even simpler) than that of the
- 6502, with the exception that floating point operations will not only be built
- in (no more having to deal with FACC's and stuff). When I see the instruction
- sets, I'll be sure to let you know, but it looks like the heyday of the
- Monster Instruction Set (MIS) is soon to expire.
-
- As much as I've enjoyed toying with IBM machines, I think I'll enjoy those
- computers almost as much as I enjoyed the 128 and the Amiga.
- ------------
- Category 2, Topic 20
- Message 17 Fri Dec 02, 1994
- D.TUOMI [Doctor] (Forwarded)
-
- I wonder if a 6502 would qualify as a RISC processor? There is some dispute
- as to exactly what a RISC processor is. For example, the Alpha supposedly has
- more instructions than a 80x86 chip, but yet its still considered a RISC chip.
- The 6502 doesn't have a lot of instructions, and its fairly efficient about
- the way it processes. So, perhaps one could think of a 6502 based Commodore
- machine as a prototype RISC computer.
-
- Doc.
- ------------
- Category 2, Topic 20
- Message 18 Fri Dec 02, 1994
- BEN.GELAMP [Ben] (Forwarded)
-
- I've often thought the same thing myself.
-
- Nebbermind what I might have forgotten or misremembered (or misread :sigh:),
- I'll still claim that learning machine language on the C128 was (is) easier
- than on any other machine I know of, partly because its instruction set is so
- small, partly because it was (is) unkillable and because the Commodore
- operating system was easy to deal with.
-
- Could the 6502 have been a doable CPU in "real" computers? Maybe. Several
- changes would have to be made, including (but not limited to)
-
- * faster processing!
- * 32 or 64 bit absolute and relative addressing
- (makes relocatable code possible)
- * more internal registers
- * relocatable stacks
-
- Fact is, the 6502 really did (does) have a very limited instruction set, to
- the point of true minimalism: how many of us have said "I'd kill for a TXY
- instruction, or a .Z register, or .."?
-
- One of the things *included* in the RISC chips, is floating point math. They
- also have "instruction pipes" - for example, it is literally common practice
- for those chips to execute a floating point operation, an integer operation
- and a branching operation simultaneously (please don't ask me for more detail,
- this is all stuff my RISC-based boss told me).
-
- Do RISC chips have more instructions than CISC? I honestly don't know yet.
- It's certain they won't have the problems an IBM has of dealing with 16-or 32-
- bit "segment" and "offset" registers or selectors (somewhat like bank# and
- address components on a C128), they'll be flat 32 or 64 bit model programming.
- The 68000 has "modes", where any given instruction has many different
- meanings, each selected by putting the processor in the appropriate mode -
- that is also gone in the RISC chip (and I can't think of a 6502 equivalent at
- the moment).
-
- I believe the idea behind a RISC isn't so much to reduce the numbers of
- instructions as their inherently byzantine nature on the current crop of
- industrial-strength desktop numbercrunchers.
- ------------
- Category 2, Topic 20
- Message 19 Fri Dec 02, 1994
- C128.JBEE (Forwarded)
-
- I believe the idea behind RISC chips was to reduce the number of instructions
- the chip has to search through to execute an instruction that has been
- submitted to the chip.
- ------------
- Category 2, Topic 20
- Message 20 Sat Dec 03, 1994
- CMD-DOUG (Forwarded)
-
- All of these things:
-
- * faster processing!
- * 32 or 64 bit absolute and relative addressing
- (makes relocatable code possible)
- * more internal registers
- * relocatable stacks
-
- are available in 65xx family processors. The 65816 and 65832 processers offer
- 16 and 32 bit power with a 6502 compatible instruction set. They come in
- speeds up to 20MHz. They have additional registers and relocatable stacks.
- They offer wider addressing to larger amounts of memory, and even have the
- ability to support co-processors and virtual memory. The 65816 even has a 6502
- emulation mode, which blocks off the extra features when attempting to
- maintain compatibility with older software. And these new processors were all
- designed by hand by one of the original designers of the 6502 - Bill Mench of
- Western Design Center (formerly with MOS Technology). Even the standard 65C02
- has been updated and enhanced with time by Bill's firm, with current versions
- offering important new instructions (such as BRA - BRanch Always) and high
- speeds (20MHz using .8 micron processes).
- ------------
- Category 2, Topic 20
- Message 21 Sat Dec 03, 1994
- D.TUOMI [Doctor] (Forwarded)
-
- So, the argument still stands. Could the 6502 be called a RISC processor. It
- certainly has a "reduced" instruction set, even compared with some of its
- contemporaries like the 8080 and Z80. Its more powerful decendents meet the
- qualifications for 32bit and 16bit computing. As to "real" computing. I'm
- not sure what lies in your philosophy, but the 128 appears to be a consistant
- object within this reality, there-fore its likely to be as real as anything
- else within this reality.
-
- Doc.
- ------------
- Category 2, Topic 20
- Message 22 Sat Dec 03, 1994
- BEN.GELAMP [Ben] (Forwarded)
-
- Hmm.. I knew of the advanced versions of the 6502; one of them powers the
- Apple GS, if I remember correctly.
-
- Would speeds beyond 20 MHz be possible? By todays's standards, a 33 MHz
- 386 is at the LOW end of acceptable speed - if you've never run AutoCAD or
- Windows, you'll know why.
-
- ------------
- Category 2, Topic 20
- Message 23 Sun Dec 04, 1994
- D.TUOMI [Doctor] (Forwarded)
-
- MHZ isn't a speed rating, its the number of pulses that the system clock
- cycles per second. Since different processors process different op-codes
- under a different number of cycles, it makes comparing processors by MHZ
- rating unreliable. This is partially the reason for the increase in speed on
- RISC chips is that since they have fewer op-codes they can do tasks in fewer
- cycles, and thus be faster. I've heard the 6502 series running at 1mhz to be
- comparable to a 8088 running at 4mhz, and a 6502 running at 2mhz to be
- comparable to a 8088 running at 8mhz. This is probably very debatable, and
- probably depends on the instructions beging executed, but if that analogy
- holds true then a 20mhz 6502 would be comparable to a 40mhz 8088. And if you
- were talking about a 16 or 32bit version, then it would be more like the 80x86
- series, but still requiring fewer processor cycles to do the same tasks.
-
- Doc.
- ------------
- Category 2, Topic 20
- Message 24 Sun Dec 04, 1994
- BEN.GELAMP [Ben] (Forwarded)
-
- Makes good sense to me; few of the commonly used indicators of speed give
- any *absolute* idea of actual throughput in any event, and are therefore just
- that: indicators (BTW, say what you will, the 4 MHz Z80 in the C128 seemed
- faster than the 286-12, at times!)
-
- A 486DX2-66 is a 486 clock-doubled 33 MHz CPU accessing memory and many
- other external components on a 32-bit bus, and so it will *execute* the
- instructions twice as fast as a 486DX-33 that's otherwise similarly equipped,
- and the 486DX-33 will operate considerably faster than a 386DX-33, for similar
- reasons (the 486 CPU is much faster). And, a 386DX-33 will run a darn sight
- faster overall than a 386SX-33 because the 386SX only has a 16- bit bus,
- meaning that fewer data can make it from memory to CPU and back in a given
- amount of time.
-
- None of which is worth a tinkerer's diddly if the system depends on a 120ms
- hard drive (today's standards are closer to 10ms) for programs and data file
- access - any such machine running Windows or compiling a massive project in C
- is going to run like four-banger Chevette with a tank full of molasses and
- three missing spark plugs.
-
- In general, no system ever performs any better than the least of its
- components.
-
- Using MHz as an indicator of speed might not be reliable, but it does
- furnish an important clue as to what kind of performance to expect. At this
- point in time, I would suspect that even if the 8088 itself were brought up to
- 66 MHz, its performance would be such that only the most uninitiated computer
- user (or economically burdened) would purchase such a machine; its actual
- processor throughput simply would not compare.
-
- The many other details of CPU construction, ones whose contributions simply
- cannot be compared with "indicators of speed" are also crucial to overall
- performance. Some of these include "instruction pipes" and "pre- fetch",
- others include the bus size and speed, speed of the video and disk subsystems,
- and no doubt other innovations will appear that I've not begun to imagine yet.
-
- Given these kinds of considerations, I ask again: could the 65* series of
- microprocessors be brought up to levels to handle today's demands?
-
- (Please say YES, and back it up! I'd LOVE to get back into 6502 assembly!)
- ------------
- Category 2, Topic 20
- Message 25 Sun Dec 04, 1994
- CMD-DOUG (Forwarded)
-
- YES, and get back to working with the 6502. ;)
-
- Western Design Centers, who makes the 65816 and 65C02, rates the the 20 MHz
- 65816 as equal to a 33 MHz 386. They didn't state if this was a DX or SX, or
- at least I don't recall it. However, this is a rating of raw processing power,
- and I think it's important to note that the kind of software commonly used on
- 386-based MS-DOS machines these days is extremely inefficient. With most users
- of those machines running compiled software under Windows, which in turn is
- running on top of MS-DOS... well, I think you get the picture.
-
- By the way, there IS a new supported method of rating different processor
- types against each other now, due to the comparisons going on between Pentium
- and PowerPC proponents. The new specifation is called SPEC. I don't have any
- details, though, but I've seen it talked about a little in a few recent
- articles, and have seen some of the comparison figures it yielded for the
- Pentium and PPC. But I doubt we'll see any comparisons with 6502's.
-
- Is the 6502 a RISC processor? Technically, no. It's a pipelined processor. But
- the instruction set is so small and the pipelining is so efficient that I
- doubt if RISC implementation of a similarly powered processor would yield any
- relevent increase in throughput.
-
- Is a 33 MHz version of the 6502 possible? Sure, if someone is willing to
- design a lower power, smaller channel version. The ability to increase the
- speed to 20 MHz has come through the latter, since WDC now uses a .8 micron
- process. Lowering the operating voltage makes going to a smaller process more
- feasable. New Pentiums and PPC processors are now being manufactured with a .6
- micron process, and at least new PPC's are due soon in a .4 micron version.
- The really high-speed pentiums are running at 3VDC now, I believe, instead of
- 5VDC. Not sure about the PPC voltages. Anyway, if WDC had the equipment and
- the desire, they've certainly got the know-how to create much faster versions
- of the 6502 and their other cousins.
- ------------
-
- 2 |