Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!swrinde!ucsd!ogicse!zephyr.ens.tek.com!gvgpsa!gold.gvg.tek.com!shaunc
From: shaunc@gold.gvg.tek.com (Shaun Case)
Newsgroups: comp.sys.apple2
Subject: Re: Modem usage in applesoft basic (sorry)
Message-ID: <2208@gold.gvg.tek.com>
Date: 23 Apr 91 04:21:23 GMT
References: <1991Apr20.054824.22158@nntp-server.caltech.edu> <2206@gold.gvg.tek.com> <1991Apr23.030502.3990@nntp-server.caltech.edu>
Organization: Grass Valley Group, Grass Valley, CA
Lines: 87

In article <1991Apr23.030502.3990@nntp-server.caltech.edu> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes:
>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.

Well, I'm afraid I have to agree with you that what I mentioned above isn't 
what happens too often, from first hand experience.  Due to that, there is
some application of t & t technology to patch difficulties in older products,
but people just re-invent the wheel a lot of the time.  As I'm sure you know
this sort of thing isn't limited to high-tech fields -- just about any field
that deals with complicated systems of any kind (including sociopolitical
systems) has the same problem with people not looking at what has been 
done already, and just forging blindly ahead (sometimes into disaster.)

>>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.

I agree with you, but as you know, there are always tradeoffs.  Making the
machine easier to program might have impacted negatively on some other "user
friendly" (user-sycophantic?) feature that corporate & marketing thought was
important.  About the only thing they can do now is release powerful
development tools, since the basic machine architecture is set in stone until
the next family is unveiled (which may well be never.)

>>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.

Again, I agree.  It's almost as useful to me as a Commodore PET-based workstation.


>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?)

Here we diverge.  I think the idea of a processor that has all instructions
equal in length, with the same as the register size, and the same size as
the instruction bus (and possibly the data bus too, if you are going with an HA)
is the way to go.  Sure, in a 32 or 64 bit processor, you have way more instructions
than you need, but what you can do with them is put in 1024 or 2048 1-word registers,
and put in addressing modes to move any register to any other register or to memory,
or mem -> any reg, and do math between large numbers of registers.  I'd like to see
the stack disappear completely, and I would like to see the stupid normalization
that goes on for reading and writing IEEE floats to/from memory to go away too.
All this can go away with lots and lots of registers.  Word wide instructions
over a word-wide bus into a word-wide register require just one memory access
(or less if you have a cache), especially if all the data is in the registers
already, and all you have to do is read the opcode.  Also, (fortune-teller time)
as bigger static rams become cheaper, cache sizes will increase to the point
where you can fit the same number of word-wide instructions into your instruction
cache as you can fit compressed instructions in a current cache for the same
percentage of machine parts cost.  When you have cheap ram, fast instruction
fetch/decode/execute and it's easy to write good compilers, how can you lose?
(ans: by putting a windowing GUI on it!  Ow, put away that flamethrower!  :-) )

BTW, are you use Henessey and Patterson?

Shaun.

(Yeah, 1024 regs.  10 bits src reg, 10 bits dest reg,  with 22 bits left for
reg/mem specification plus operation specification.  Wonder how small you
could make the die?)

Maybe we should move this to email or a more appropriate newsgroup.
Suggestions?