toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (02/16/91)
rhyde@koufax.ucr.edu (randy hyde) writes: > From this standpoint I guess you could claim that the 6502's >instruction set "prefers" an eight-bit bus. Gee, that was my point... 'prefers' is a sort of metaphor to avoid lengthy explanation, like chemists saying that electrons 'prefer' to be in certain orbitals. >going to a 16 or 32-bit bus would provide very little in the way of >performance improvement! > After discussing this with Mr. Mensch, He led me to believe a 16-bit access >would still take 5 cycles, even on a 16-bit bus. This is lousy microcode I'll say it is. I agree with Mensch when it comes to simplicity in the instruction set, but using brain-dead microcode on a wide bus is idiotic. The 80386 does 32 bit reads into a byte wide instruction pipeline, which strikes me as a fairly simple (if slightly nondeterministic) and elegant way to handle a byte oriented instruction stream on a wide bus. >the chip, using modern design techniques, could run much faster than an >equivalently clocked 65c816. I don't doubt that. I felt that you were really designing your own CPU using concepts from the 65816 (and heavily borrowing from the 68000) so you might as well call it a new CPU entirely. This is what I didn't like about your article and I am sorry for saying 'disgusted' because that really is too loaded a word to describe my opinion of it. I felt that the 65820 idea was a 68000 wanna-be and that what you were really talking about was a bank switch between a 6502 and a 68000 -- which is inappropriate to the goal of improving the 65816 rather than replacing it entirely. >Of course the whole discussion is a moot point since this chip will >never exist. True. The 65832 might, however, and if Mensch actually does a competent job of it then it will remain true to the philosophy that makes it one of the best lightweight controller chips. >But since my design "disgusts" you, why don't *YOU* write an article >describing something which is better. (1) I haven't figured it all out yet. (2) I am still a Junior in college and not comfy in a research job. (3) My free time is almost entirely absorbed in cranking out GS stuff some of which will finally be releasable in a week or so, and none too soon because I need the money. > Quite honestly, the only way you're going to convince us otherwise is to > actually write the code. In other words, "put up or shut up." > You claim a decent compiler can be written for the GS. I've yet to see it. > Prove me wrong. Prove a good compiler can be written, write it! Dammit, I'm only human and I'm far from independently wealthy! A compiler is a pretty tough project for one person (although I am taking a class on programming paradigms and compilers next term). When I get it working, I'll post it. But it'll probably have to wait until the GIFfer and the PostScript downloader have real interfaces, and the subtitler and chatter are written, and the TCP/IP code is functional... [lots of decreasingly objective stuff deleted] > it's another thing to call my work disgusting. Yes, it is. I really shouldn't have said that. I wish to formally apologize for calling the 65820 paper "disgusting". It was an inappropriate word to use and did not properly reflect my differences with the 65820 design. Todd Whitesel toddpw @ tybalt.caltech.edu
gwyn@smoke.brl.mil (Doug Gwyn) (02/17/91)
In article <1991Feb16.053155.8278@nntp-server.caltech.edu> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: >The 80386 does 32 bit reads into a byte wide instruction pipeline, which >strikes me as a fairly simple (if slightly nondeterministic) and elegant >way to handle a byte oriented instruction stream on a wide bus. Of course, you cannot DO that on an Apple II, due to the way the soft switches are organized. A 65xx family member that exploited this would be of use in a purely toolset- or kernel-oriented approach to accessing the system features, however.
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (02/17/91)
gwyn@smoke.brl.mil (Doug Gwyn) writes: >In article <> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: >>The 80386 does 32 bit reads into a byte wide instruction pipeline, which >Of course, you cannot DO that on an Apple II, due to the way the soft >switches are organized. I disagree. Instructions come from memory (mostly) which can easily be organised as 32 bits, even with bank-switched ram. For I/O, the CPU can do cheap dynamic bus sizing -- this is something most wide bus CPU's have, for exactly these reasons. Many popular I/O chips have interfaces whose operation is sometimes more bizarre than the Apple II softswitches ... >A 65xx family member that exploited this would be of use in a purely toolset- >or kernel-oriented approach to accessing the system features, however. Fine by me. We can trap any attempt to access the old registers and kill the process with a dialog like 'FTA_Modulae killed, illegal hardware access' ... When the system is fast enough to make every tool worth using, software will rally around the tools and non-tool software will be replaced almost as fast as it starts crashing. The Amiga hasn't been able to do this though... Todd Whitesel toddpw @ tybalt.caltech.edu