Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!jarthur!nntp-server.caltech.edu!toddpw From: toddpw@nntp-server.caltech.edu (Todd P. Whitesel) Newsgroups: comp.sys.apple2 Subject: Re: Modem usage in applesoft basic (sorry) Message-ID: <1991Apr23.030502.3990@nntp-server.caltech.edu> Date: 23 Apr 91 03:05:02 GMT References: <9104200147.AA05353@apple.com> <1991Apr20.054824.22158@nntp-server.caltech.edu> <2206@gold.gvg.tek.com> Organization: California Institute of Technology, Pasadena Lines: 74 shaunc@gold.gvg.tek.com (Shaun Case) writes: >I'm not saying it should be this way, just that it is. There is also >a school of thought that you should do it right the first time -- there >should be no need for putting huge amounts of effort into old technologies, >since you thought about things like expansion, reliability, and upwards >compatibility while you were still in the specification stage. Yeah, right. That's not what really happens, all too often. I suppose I should rephrase things a bit -- what I want to see is using new technologies to make the tried and true work better. This is being done, but with such a short term mindset that numbs the imagination. That's what I guess I'm really complaining about. >Additionally, Macs are targeted at a different market than the Apple 2 >series was (at first, anyway.) How many people do you know that program >their macs, percentagewise, compared to the number of people you know who >program their apple 2s? That's because programming the Mac is hell, because they really had no idea how the programmer interfaces should work. A lot more is known, now, but IMHO it is always a plus to spend resources on making a platform easier to develop for, for obvious reasons. [description of bountiful ROM machine deleted] >This is a pretty good description of the IBM PS/1, I think. Really? That's an encouraging sign. Too bad they had to waste it on something as bizarre as the PS/1. >>The point is, not only is the computer self-sufficient, but it's USABLE FASTER >>than computers that are dependent on system disks just to run. Boot time is >Rah! I'm all for that. If you are a computer designer, take a look at Intel's >Flash memory technology, especially the JEDEC 2 devices. It is intended for >just such an application. Hmmm... I don't have a job in design (yet, I hope), but I try to keep up with data books and such (I'm on TI's mailing list). I'll look into it. (While I'm still in college I have to be content with 'armchair design' for this sort of thing...) >Well, if you want it to run multiple processes well, you need virtual memory >support and task switching stuff on the processor, which takes away some of >the "reasonable"ness. It better be at least 32 bits, too, unless you want >your machine to be obsolete before you get one off the line. :-P I know, and I don't think it HAS to take away the "reasonable"ness although that appears to have happened a lot (maybe I need to look at the real state of the art though; I haven't run across SPARC chip data sheets at all yet). 32 bits is a must for new architectures although I wish the instruction sets didn't take up so much space. The process of designing an instruction set is not unlike defining a compression scheme for all the possible instructions the CPU has -- most modern studly RISC CPUs appear to be using none at all for sake of speed. The 80x86 family seems to use the most 'compression' but most of it is derived from the extreme nonorthogonality of the instruction set, which can be a real annoyance when one is programming for it. The 65xxx is about midway: instructions are no larger than they need to be but they each perform a single operation (no postdecrement type stuff), and the nonorthgonality is bearable and in many cases is desirable, because it allows more useful operations to be crammed into the same single byte opcode. I think the real problem is that nobody has tried (please correct me, I'd like to see it) to deliberately encode a well-designed RISC instruction set into variable length instructions. I know it can be done with CISC sets (yeah Randy, the 680x0) but I'm not aware of a studly RISC chip that does it. Chips designed to reduce the overhead of reading the instruction stream _period_ "should" (I'm predicting now) use the available cache RAM and memory bandwidth far more effectively. (If it's already being tried, then that's great, who's doing it?) Todd Whitesel toddpw @ tybalt.caltech.edu