> From: Lawrence Wilkinson
> Nothing to report other than what's at https://ibms360.co.uk
Any partial results in trying to figure out a way to get all the
stuff back from Nuremberg?
You all may wind up having to rent a large truck yourselves, alas...
Noel
I finally got around to reading that note. My principal reponse is that it got so
far down into details that I couldn't see the larger picture any more.
Going back to the original IBM 801 work, the RISC concept is very simple: to make
the overall system as fast as possible; it did this by making the CPU cycle time
as short as possible. This results in a CPU that is not as easy to work with;
therefore the compiler has to be 'smarter'. In other words, engineering complexity
is moved from the hardware to the software.
This is an an acceptable tradeoff; the complexity in the software is not a recurring
cost, whereas extra gates add cost to every machine produced. Moreover, while the
more complex compiler may be more time-consuming to run, that cost is only paid
once, whereas the efficiency of the binary is felt every time the program is run.
Focusing on what features a CPU does or does not have in some ways misses the
whole point of RISC: it's not about what specific features the CPU has, in
isolation; it's about looking at the system as a whole, all the way up through
the compilers, to maximize performance.
I recall Tom Knight laying out the implication for CPU design very simply, in a
seminar I took back when the idea had just come out: look at the CPU design, and
find the longest signal path; this will set the lower limit on the clock time.
Redesign to remove that path; since the capability that needed it will inevitably be
used only part of the time, the execution increase caused by losing it will be
outweighed by the speedup of all the other instructions.
The other thing one needs to remember, talking about RISC, is that it's now
been almost 40 years since the concept was devised (an eternity in the computing
field), and the technology environment has changed drastically since then. So
RISC has changed and adapted as that environment changed.
Nowadays, when people throw a billion transistors at each CPU, the picture is
somewhat different. Register widows were just the first instance of this sort of
thing; we have this unused area of the chip, what can we put there?
>> On 6/15/19 3:40 PM, ben via cctalk wrote:
>> CISC design is now needed to handle the 'extended features'. ... RISC came
>> along only because Compilers could only generate SIMPLE instructions, that
>> matched the RISC format.
No; compilers had been created that could use the more complex CISC instructions of,
say, a VAX. RISC post-dated a lot of those developments, and had an entirely
different point.
> From: Chuck Guzis
> For what it's worth, the number of instructions in the ISA does not define
> RISC, but rather that the instructions execute quickly. Some RISC
> implementations have large instruction sets.
Right; what's reduced is the complexity of the instructions, which leads to
the speedup which is the goal, not the number of them.
In fact, a RISC CPU may actually have more instructions, e.g. separate ones
for different cases, with the compiler being given the responsibility of
picking the right one, instead of the CPU figuring it out as it goes.
> RISC does carry a penalty in that you're executing more instructions to get
> something done, so your code space is larger; but, you hopefully have them scheduled
> such that the whole task runs faster.
This in another aspect, which I've mentioned before, behind the rise of RISC, which
is the changing size and speed of main memory, relative to the CPU. Simpler
instructions are faster, but a given task will need more of them. This is acceptable
if the memory can supply them fast enough. If the memory bandwidth is less, more
complex instructions make sense, to get more out of the limited bandwidth.
Also, if memory is of limited capacity, or expensive, then more complex instructions
make sense, since more can be done with a fixed amount of memory. (The PDP-11 still
scores very high in code density.) This too, however, has been overtaken by the
march of technology.
Still, the basic idea of RISC still applies; make the CPU clock rate as fast as
possible by making the instructions simple, and let software deal with the resulting
issues.
Noel
There is an elderly gent in Bedford, MA that was a DEC dealer back in the
day. The following inventory is what he has posted on a service I belong to.
He is very deaf, and he can't hear me over the phone. He is open 9-5 M-F.
Someone needs to go and dig. I don't think he knows where everything is
anymore, and I don't think he can reach high places or lift medium-heavy
things.
Not affiliated with seller, etc.
Charlie Burgess
119A Great Road
Bedford, MA 01730-2720
781-275-6800
qeiinc at verizon.net
0132727
03-211265-0
06-888E7620
06-98805420
06-98826020
06141
10-09397-01
10-13102-00
10028002
10028102
10058100
10104
101066
10183/10184
109831-00L
11-10364
11/23-AW
11/34A-HC
11/730
11/750-CA
11/84-AC
1110
11130-DC
11150-CH
11213
11214
11592-906-1
117838-A
12-04403-01
12-09403-01
12-10152-0
12-11196-02
12-11477
12-11519
12-11563
12-11580-01
12-11581-00
12-11583-00
12-11583-01
12-12157-00
12-12199-00
12-12904-00
12-13097-00
12-13185-00
12-13186-00
12-13369-00
12-13686-00
12-14333-JO
12-14360-00
12-14614-02
12-15050-00
12-15292-00
12-1529600A
12-15297-00
12-15336-00
12-15336-08
12-15336-11
12-15360-00
12-15394-00
12-15558-00
12-15633-00
12-15663-00
12-16166-00
12-16166-02
12-16308-00
12-16391
12-16552
12-16827-00
12-17431-00
12-17431-01
12-17474-00
12-17606
12-18320
12-18416-00
12-18633-00
12-19245
12-19245-00
12-19245-01
12-19266
12-20267-01
12-22196-01
12-22196-02
12-22271-01
12-22707-01
12-23196-01
12-23607-04
12-23609-04
12-23609-11
12-23609-15
12-23609-19
12-23609-21
12-24701-10
12-26339-01
12-27591-01
12-28258-01
12-28508-01
12-29258-01
12-29635-01
12-30552-01
12-32022-01
12-32728-01
12-33626-01
12-35173-01
12-35759-01
12-39921-02
12-45246-03
120119-01
123
1351922
13C27A-30
1412DA
16-12256-0
16-12398
16-12497-01
16-1389700B
16-14110-00
16-17186-01
16-19001-01
1616-010
1632TTL
1664ATTL
17-000-82-0
17-00004-00
17-00079-00
17-0008202D
17-00083-06
17-00083-10
17-00083-37
17-00083-49
17-00087-00
17-00100-00
17-00107-01
17-00193-00
17-00198-15
17-00233
17-00254-00
17-00254-01
17-00277-04
17-00280-00
17-00282-00
17-00282-01
17-00282-03
17-00284-00
17-00285-00
17-00285-02
17-00286
Cindy Croxton
Electronics Plus
1613 Water Street
Kerrville, TX 78028
830-370-3239 cell
sales at elecplus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Hello fellow collectors,
I have this Fairy YL-23 IC tester / programmer with ISA bus.
http://matthieu.benoit.free.fr/Fairy_YL-23_Eprom_Programmer_resources_page.…
The problem: I have no documentation and no software for it.
Can anyone help me getting PC software for it?
Thanks in advance!Regards, Roland Huisman
The system consists of:
1) a 19" rack-mountable CPU chassis
2) a 19" rack-mountable floppy-disk drive (and bootable RT-11 floppy-disks)
3) Zenith Z-29-A RS232 terminal
The boards included are:
M8186 KDF11-A 11/23 CPU
????? 256KB parity RAM
????? DSD-440 floppy disk interface
????? bus grant continuity card
M8028 DLV11-F Async interface
M8012 BDV11 Bus terminator, bootstrap and diagnostic ROMs
M8016 KPV11 Power fail, realtime clock, (termination)
Also included are several 8" floppy disks with RT/11 and other system
software.
If interested, send me a message.
Thanks,
Scott
When I worked for Burroughs/Unisys, I was one of the last people working
on software for B1000. I think I was the sole user of the B1965 at their
Lake Forest (Orange County) California office in '88-89. I was
surrounded in my cubicle by all of the disk packs for that system. My
favorite systems while at Burroughs was the B1000s.
One of those type of disk packs is up on eBay right now and I am trying
to decide whether to buy it. It is $60 plus another $40 for shipping. Is
that too much? I almost never see Burroughs stuff, so, if I want
Burroughs stuff, I should just get it, right?
alan
> From: Alan Perry
> a chance to see and touch something that I haven't seen in decades
> that was once a big part of my life.
I know exactly what you mean. PDP-11's were a huge part of my professional
life:
-11/20: the first computer I actually used, in high school
-11/45: the computer on which I took my first programming course in
the CS Dept (amazingly, my group later traded the next computer
for that very computer, years later)
-11/40: the first computer that was 'mine', in the sense that I
controlled it
-11/70: the computer I did a lot of my early Unix learning/work on
-11/03: my first packet switch code ran on one of these
-11/23: the most widespread machine that my early packet switches ran
on
-11/73: the timesharing machine at the company that productized my
packet switch code
I'm very fortunate to now have a lot of PDP-11's in my collection.
(Including an /04 and a /34, machines I never used BITD.) I had no contact
with PDP-11's for many years, but only a few years ago someone here gave
me an -11/84 (if I drove to Wisconsin to get it :-); I stopped off at my
in-law's house to overnight on the way back with it, and they later told
my wife it was the happiest they'd ever seen me!
Noel
