What's Your Favorite Processor on an FPGA?

[rickman]

I have been working on designs of processors for FPGAs for quite a
while. I have looked at the uBlaze, the picoBlaze, the NIOS, two from
Lattice and any number of open source processors. Many of the open
source designs were stack processors since they tend to be small and
efficient in an FPGA. J1 is one I had pretty much missed until lately.
It is fast and small and looks like it wasn't too hard to design
(although looks may be deceptive), I'm impressed. There is also the b16
from Bernd Paysan, the uCore, the ZPU and many others.

Lately I have been looking at a hybrid approach which combines features
of addressing registers in order to access parameters of a stack CPU.
It looks interesting.

Anyone else here doing processor designs on FPGAs?

--

Rick

[Bill Sloman]

Sounds like something where you'd get more responses on comp.arch.fpga.

Are you cross-posting?

--
Bill Sloman, Sydney

[John Larkin]

My guys have been ragging me for years to do designs that have soft-core CPUs in
FPGAs, but I've been able to convince them (well, I am the boss) that they
haven't made sense so far. They use up too much FPGA resources to make a
mediocre, hard to use CPU. So we've been using separate ARM processors, and
using a bunch of pins to get the CPU bus into the FPGA, usually with an async
static-ram sort of interface.

There's supposed to be a Cyclone coming soon, with dual-hard-core ARM processors
and enough dedicated program RAM to run useful apps. When that's real, we may go
that way. That will save pins and speed up the CPU-to-FPGA logic handshake.

If the programs get too big for the on-chip sram, I guess the fix would be
external DRAM with CPU cache. There goes the pin savings. At that point, an
external ARM starts to look good again.


--

John Larkin Highland Technology Inc
www.highlandtechnology.com jlarkin at highlandtechnology dot com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators

[rickman]

The choice of an internal vs. an external CPU is a systems design
decision. If you need so much memory that external memory is warranted,
then I guess an external CPU is warranted. But that all depends on your
app. Are you running an OS, if so, why?

The sort of stuff I typically do doesn't need a USB or Ethernet
interface, both great reasons to use an ARM... free, working software
that comes with an OS like Linux. (by free I mean you don't have to
spend all that time writing or debugging a TCP/IP stack, etc)

But there are times when an internal CPU works even for high level
interfaces. In fact, the J1 was written because they needed a processor
to stream video over Ethernet and the uBlaze wan't so great at it.

I get the impression your projects are about other things than the
FPGA/CPU you use and cost/size really aren't so important. Then you
have less reason to squeeze on size, power, unit costs, but rather
minimize development cost. If so, that only makes sense.

My next project will be similar in hardware requirements to a digital
watch, but with more processing...

--

Rick

[John Larkin]

FPGA ram is expensive compared to the SRAM or flash that comes on a small ARM,
like an LPC1754. Something serious, like an LPC3250, has stuff like hardware
vector floating point and runs 32-bit instructions at 260 MHz. Both the ARMs
have uarts, timers, ADCs, DACs, and Ethernet, for $4 and $7 respectively.

We generally run bare-metal, a central state machine and some ISR stuff. I've
written three RTOSs in the past but haven't really needed one lately.

>
>The sort of stuff I typically do doesn't need a USB or Ethernet
>interface, both great reasons to use an ARM... free, working software
>that comes with an OS like Linux. (by free I mean you don't have to
>spend all that time writing or debugging a TCP/IP stack, etc)

Yeah, we use the GCC compilers. Stuff like Ethernet and USB stacks are available
and work without much hassle. I don't know what the tool chains are like for the
soft cores.

>
>But there are times when an internal CPU works even for high level
>interfaces. In fact, the J1 was written because they needed a processor
>to stream video over Ethernet and the uBlaze wan't so great at it.
>
>I get the impression your projects are about other things than the
>FPGA/CPU you use and cost/size really aren't so important. Then you
>have less reason to squeeze on size, power, unit costs, but rather
>minimize development cost. If so, that only makes sense.

We do a fair amount of "computing", stuff like signal filtering, calibrations
with flash cal tables, serial and Ethernet communications, sometimes driving
leds and lcds. There have been a minority of apps simple enough to use a
microblaze, and I didn't think that acquiring/learning/archiving another whole
tool chain was worth it for those few apps, what with an LPC1754 costing $4.

>
>My next project will be similar in hardware requirements to a digital
>watch, but with more processing...

Sometimes you can just do the computing "in hardware" in the FPGA and not even
need a procedural language. So the use case gets even smaller.

I am looking forward to having a serious ARM or two (or, say, 16) inside an
FPGA. With enough CPUs, you don't need an RTOS.

[rickman]

That is not a useful way to look at RAM unless you are talking about
buying a larger chip than you need otherwise just to get more RAM. That
is like saying the routing in an FPGA is "expensive" compared to the
PCB. It is there as part of the device, use it or it goes to waste.

If you need Ethernet, then Ethernet is useful. But adding Ethernet to
an FPGA is no big deal. Likewise for nearly any peripheral.

No point in discussing this very much. Every system has it's own
requirements. If external ARMs are what works for you, great!

> We generally run bare-metal, a central state machine and some ISR stuff. I've
> written three RTOSs in the past but haven't really needed one lately.

What do you do for the networking code. If you write your own, then you
are doing a lot of work for naught typically, unless you have special
requirements.

>> The sort of stuff I typically do doesn't need a USB or Ethernet
>> interface, both great reasons to use an ARM... free, working software
>> that comes with an OS like Linux. (by free I mean you don't have to
>> spend all that time writing or debugging a TCP/IP stack, etc)
>
> Yeah, we use the GCC compilers. Stuff like Ethernet and USB stacks are available
> and work without much hassle. I don't know what the tool chains are like for the
> soft cores.

So you are using networking code, but no OS?

The soft cores I work with don't bother with that sort of stuff. The
apps are much smaller and don't need that level of complexity. In fact,
that is what they are all about, getting rid of unneeded complexity.

>> But there are times when an internal CPU works even for high level
>> interfaces. In fact, the J1 was written because they needed a processor
>> to stream video over Ethernet and the uBlaze wan't so great at it.
>>
>> I get the impression your projects are about other things than the
>> FPGA/CPU you use and cost/size really aren't so important. Then you
>> have less reason to squeeze on size, power, unit costs, but rather
>> minimize development cost. If so, that only makes sense.
>
> We do a fair amount of "computing", stuff like signal filtering, calibrations
> with flash cal tables, serial and Ethernet communications, sometimes driving
> leds and lcds. There have been a minority of apps simple enough to use a
> microblaze, and I didn't think that acquiring/learning/archiving another whole
> tool chain was worth it for those few apps, what with an LPC1754 costing $4.

Ethernet comms can be a hunk of code, but the rest of what you describe
is pretty simple stuff. I'm not sure there is even a need for a
processor. Lots of designers are just so used to doing everything in
software they think it is simple.

Actually, I think everything you listed above is simple enough for a
uBlaze. What is the issue with that?

I find HDL to be the "simple" way to do stuff like I/O and serial comms,
even signal processing. In fact, my bread and butter is a product with
signal processing in an FPGA, not because of speed, it is just an audio
app. But the FPGA *had* to be there. An MCU would just be a waste of
board space which this has very little of.

>> My next project will be similar in hardware requirements to a digital
>> watch, but with more processing...
>
> Sometimes you can just do the computing "in hardware" in the FPGA and not even
> need a procedural language. So the use case gets even smaller.
>
> I am looking forward to having a serious ARM or two (or, say, 16) inside an
> FPGA. With enough CPUs, you don't need an RTOS.

Xilinx has that now you know. What do they call it, Z-something? Zync
maybe?

How about 144 processors running at 100's of MIPS each? Enough
processing power that you can devote one to a serial port, one to an SPI
port, one to flash a couple of LEDs and still have 140 left over. Check
out the GreenArrays GA144. Around $14 the last time I asked. You won't
like the development system though. It is the processor equivalent of
an FPGA. I call it a FPPA, Field Programmable Processor Array. It can
be *very* low power too if you let the nodes idle when they aren't doing
anything.

--

Rick

[John Larkin]

We got an Ethernet stack somewhere. It's flag driven into the central state
machine. If there's an input buffer full, we get a flag, and the state machine
processes it when it gets around to it. It may build an outgoing message and
queue that into the stack, which runs mostly at interrupt level. A typical
system would parse incoming commands and generate replies. It's awfully simple.
We usually share the whole parser/executor/reply generator code among multiple
ports concurrently, like USB and Ethernet and serial; the buffers and flags all
look alike.

>
>
>>> The sort of stuff I typically do doesn't need a USB or Ethernet
>>> interface, both great reasons to use an ARM... free, working software
>>> that comes with an OS like Linux. (by free I mean you don't have to
>>> spend all that time writing or debugging a TCP/IP stack, etc)
>>
>> Yeah, we use the GCC compilers. Stuff like Ethernet and USB stacks are available
>> and work without much hassle. I don't know what the tool chains are like for the
>> soft cores.
>
>So you are using networking code, but no OS?

Right.

>
>The soft cores I work with don't bother with that sort of stuff. The
>apps are much smaller and don't need that level of complexity. In fact,
>that is what they are all about, getting rid of unneeded complexity.
>
>
>>> But there are times when an internal CPU works even for high level
>>> interfaces. In fact, the J1 was written because they needed a processor
>>> to stream video over Ethernet and the uBlaze wan't so great at it.
>>>
>>> I get the impression your projects are about other things than the
>>> FPGA/CPU you use and cost/size really aren't so important. Then you
>>> have less reason to squeeze on size, power, unit costs, but rather
>>> minimize development cost. If so, that only makes sense.
>>
>> We do a fair amount of "computing", stuff like signal filtering, calibrations
>> with flash cal tables, serial and Ethernet communications, sometimes driving
>> leds and lcds. There have been a minority of apps simple enough to use a
>> microblaze, and I didn't think that acquiring/learning/archiving another whole
>> tool chain was worth it for those few apps, what with an LPC1754 costing $4.
>
>Ethernet comms can be a hunk of code, but the rest of what you describe
>is pretty simple stuff. I'm not sure there is even a need for a
>processor. Lots of designers are just so used to doing everything in
>software they think it is simple.

Imagine a 16-channel thermocouple simulator.

>
>Actually, I think everything you listed above is simple enough for a
>uBlaze. What is the issue with that?
>
>I find HDL to be the "simple" way to do stuff like I/O and serial comms,
>even signal processing. In fact, my bread and butter is a product with
>signal processing in an FPGA, not because of speed, it is just an audio
>app. But the FPGA *had* to be there. An MCU would just be a waste of
>board space which this has very little of.
>
>
>>> My next project will be similar in hardware requirements to a digital
>>> watch, but with more processing...
>>
>> Sometimes you can just do the computing "in hardware" in the FPGA and not even
>> need a procedural language. So the use case gets even smaller.
>>
>> I am looking forward to having a serious ARM or two (or, say, 16) inside an
>> FPGA. With enough CPUs, you don't need an RTOS.
>
>Xilinx has that now you know. What do they call it, Z-something? Zync
>maybe?
>
>How about 144 processors running at 100's of MIPS each? Enough
>processing power that you can devote one to a serial port, one to an SPI
>port, one to flash a couple of LEDs and still have 140 left over. Check
>out the GreenArrays GA144. Around $14 the last time I asked. You won't
>like the development system though. It is the processor equivalent of
>an FPGA. I call it a FPPA, Field Programmable Processor Array. It can
>be *very* low power too if you let the nodes idle when they aren't doing
>anything.

My ideal computer would have one CPU that's just the OS, and a hundred or so
assignable cores, one for each device, file system, program, or thread. The OS
would be a few thousand lines of code, if that. With serious hardware
protection, it would be totally virus/trojan/crash immune.

[bitrex]

Something like this:
http://www.tilera.com/sites/default/files/productbriefs/TILE-Gx8072_PB041-02.pdf
?

[r...@wmail.fi]

On Sunday, April 21, 2013 4:14:55 AM UTC+3, rickman wrote:

> Xilinx has that now you know. What do they call it, >Z-something? Zync maybe?

ZYNQ. There is a rather low-cost eval board, named
Zedboard ( www.zedboard.org, $395 ) which comes with
Linux pre-installed on a SD card. The ZYNQ chip
onboard contains a hard dual-core Cortex-A9 and
~1M gates worth 7th generation logic.

Regards,
Mikko

[Vladimir Vassilevsky]

Soft core is fun thing to do, but otherwise I see no use.
Except for very few special applications, standalone processor is better
then FPGA soft core in every point, especially the price.

Vladimir Vassilevsky
DSP and Mixed Signal Designs
www.abvolt.com

[Vladimir Vassilevsky]

On 4/20/2013 8:37 PM, John Larkin wrote:

> My ideal computer would have one CPU that's just the OS, and a hundred or so
> assignable cores, one for each device, file system, program, or thread. The OS
> would be a few thousand lines of code, if that. With serious hardware
> protection, it would be totally virus/trojan/crash immune.

Utter nonsense.

N cores means N^2 interfaces with associated version hell.
As for protection, is not technical problem; it is paradigm problem.

[John Larkin]

On Sun, 21 Apr 2013 08:32:44 -0500, Vladimir Vassilevsky <nos...@nowhere.com>
wrote:

>On 4/20/2013 8:37 PM, John Larkin wrote:
>
>> My ideal computer would have one CPU that's just the OS, and a hundred or so
>> assignable cores, one for each device, file system, program, or thread. The OS
>> would be a few thousand lines of code, if that. With serious hardware
>> protection, it would be totally virus/trojan/crash immune.
>
>
>Utter nonsense.
>
>N cores means N^2 interfaces with associated version hell.

Better than having all N processes in the same memory space. Much better.

>As for protection, is not technical problem; it is paradigm problem.

The architecture that I propose could have absolute hardware sandboxing of any
process, even drivers and things that can do DMA. Each processor would have
memory management - loaded by the OS - that knows the difference between code,
data, and stack. The OS would be tiny, absolutely protected, known reliable.
Just note all the things that Wintel did wrong, and don't do that.

[John Larkin]

On Sun, 21 Apr 2013 08:23:37 -0500, Vladimir Vassilevsky <nos...@nowhere.com>
wrote:

The annoying thing is the CPU-to-FPGA interface. It takes a lot of FPGA pins and
it tends to be async and slow. It would be great to have an industry-standard
LVDS-type fast serial interface, with hooks like shared memory, but transparent
and easy to use.

Something like ARM internal to an FPGA could have a synchronous, maybe shared
memory, interface into one of those SOPC type virtual bus structures without
wasting FPGA pins.

[rickman]

Everyone is entitled to their opinion, but this is *far* from fact. The
CPUs in my designs have so far been *free* in recurring price. They fit
in a small part of the lowest priced device I can find.

Most people think of large, complex code that requires lots of RAM and
big, fast external CPUs. I think in terms of small, internal processors
that run fast in a very small code space. So they fit inside an FPGA
very easily, likely not much bigger than the state machines John talks
about.

BTW, have you looked at any of the soft cores? The J1 is pretty amazing
in terms of just basic simplicity, fast too at 100 MHz. They talk about
the source just being 200 lines of verilog, but I don't know how many
LUTs the design is, but from the block diagram I expect it is not very
big. I'm not sure I can improve on it in any significant way.

--

Rick

[Ralph Barone]

John Larkin <jjla...@highNOTlandTHIStechnologyPART.com> wrote:
> On Sun, 21 Apr 2013 08:32:44 -0500, Vladimir Vassilevsky <nos...@nowhere.com>
> wrote:
>
>> On 4/20/2013 8:37 PM, John Larkin wrote:
>>
>>> My ideal computer would have one CPU that's just the OS, and a hundred or so
>>> assignable cores, one for each device, file system, program, or thread. The OS
>>> would be a few thousand lines of code, if that. With serious hardware
>>> protection, it would be totally virus/trojan/crash immune.
>>
>>
>> Utter nonsense.
>>
>> N cores means N^2 interfaces with associated version hell.
>
> Better than having all N processes in the same memory space. Much better.
>
>
>> As for protection, is not technical problem; it is paradigm problem.
>
> The architecture that I propose could have absolute hardware sandboxing of any
> process, even drivers and things that can do DMA. Each processor would have
> memory management - loaded by the OS - that knows the difference between code,
> data, and stack. The OS would be tiny, absolutely protected, known reliable.
> Just note all the things that Wintel did wrong, and don't do that.
>

and end up doing making new and innovative mistakes (just channeling Murphy
here).

[lang...@fonz.dk]

On Apr 21, 6:05 pm, John Larkin

xilinx Zynq, arm9 with an fpga on the side

-Lasse

[John Larkin]

On Sun, 21 Apr 2013 17:34:12 GMT, Ralph Barone <addre...@invalid.invalid>
wrote:

DEC wrote operating systems (TOPS10, VMS, RSTS) that ran for months between
power failures, time-sharing multiple, sometimes hostile, users. We are now in
the dark ages of computing, overwhelmed by bloat and slop and complexity. No
wonder people are buying tablets. DEC understood things that Intel and Microsoft
never really got, like: don't execute data.

[John Larkin]

On Sun, 21 Apr 2013 11:09:02 -0700 (PDT), "lang...@fonz.dk" <lang...@fonz.dk>
wrote:

We gave up on Xilinx a few yeas ago: great silicon, horrendous software tools.
Altera is somewhat less horrendous.

[rickman]

On 4/21/2013 4:22 PM, John Larkin wrote:
> On Sun, 21 Apr 2013 17:34:12 GMT, Ralph Barone<addre...@invalid.invalid>
> wrote:
>>
>> and end up doing making new and innovative mistakes (just channeling Murphy
>> here).
>
> DEC wrote operating systems (TOPS10, VMS, RSTS) that ran for months between
> power failures, time-sharing multiple, sometimes hostile, users. We are now in
> the dark ages of computing, overwhelmed by bloat and slop and complexity. No
> wonder people are buying tablets. DEC understood things that Intel and Microsoft
> never really got, like: don't execute data.

You really should stick to things you understand. Every Intel processor
since the 8086 has included protection mechanism to prevent the
execution of data. But they have to be used properly... Blame
Microsoft and all the other software vendors, but don't blame Intel.
Actually, this is an issue just like so many that are determined by the
market place. When users put value on these features and spend their
money accordingly, the market will respond. So don't buy Windows
anymore if you don't like it. Microsoft will either respond or go out
of business. But that's not going to happen. People just like to
complain about MS while they continue giving them their money.

--

Rick

[upsid...@downunder.com]

On Sun, 21 Apr 2013 13:22:12 -0700, John Larkin
<jjla...@highNOTlandTHIStechnologyPART.com> wrote:

>
>DEC wrote operating systems (TOPS10, VMS, RSTS) that ran for months between
>power failures, time-sharing multiple, sometimes hostile, users.

I was responsible for some VMS-11 systems and I forgot to boot the
system every summer, when no-one was around. Booting the system the
system next year and everyone were happy :-).

>We are now in
>the dark ages of computing, overwhelmed by bloat and slop and complexity. No
>wonder people are buying tablets. DEC understood things that Intel and Microsoft
>never really got, like: don't execute data.

PDP-11/RSX-11M+ (early 1970's) had separate I/D spaces, VAX/VMS (mid
70's) had executable program sections.

[John Larkin]

On Sun, 21 Apr 2013 16:40:22 -0400, rickman <gnu...@gmail.com> wrote:

>On 4/21/2013 4:22 PM, John Larkin wrote:
>> On Sun, 21 Apr 2013 17:34:12 GMT, Ralph Barone<addre...@invalid.invalid>
>> wrote:
>>>
>>> and end up doing making new and innovative mistakes (just channeling Murphy
>>> here).
>>
>> DEC wrote operating systems (TOPS10, VMS, RSTS) that ran for months between
>> power failures, time-sharing multiple, sometimes hostile, users. We are now in
>> the dark ages of computing, overwhelmed by bloat and slop and complexity. No
>> wonder people are buying tablets. DEC understood things that Intel and Microsoft
>> never really got, like: don't execute data.
>
>You really should stick to things you understand. Every Intel processor
>since the 8086 has included protection mechanism to prevent the
>execution of data. But they have to be used properly... Blame
>Microsoft and all the other software vendors, but don't blame Intel.

The Intel memory protection is primitive. And Intel writes C compilers for their
processors, which cheerfully mix data, code, and stacks in the same space. Which
is why a simple buffer or stack overflow can plant and run hostile code in an
application. After decades of chasing buffer overflow exploits, Wintel has STILL
not managed to make them impossible. The common NOP SLED exploit works if the
data on the stack can be executed!

>Actually, this is an issue just like so many that are determined by the
>market place. When users put value on these features and spend their
>money accordingly, the market will respond. So don't buy Windows
>anymore if you don't like it. Microsoft will either respond or go out
>of business. But that's not going to happen. People just like to
>complain about MS while they continue giving them their money.

Windows sales are down, and with luck will continue to decline.

[John Larkin]

RSTS mapped code pages to be execute-only (apps couldn't write to code space)
and data/stack pages were non-executable. Stack overflow and buffer overrun
exploits were prevented by hardware. Both Intel and Microsoft were out of the
mainstream of computing, which is why we have such a mess today.

[lang...@fonz.dk]

On Apr 21, 10:24 pm, John Larkin
<jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
> On Sun, 21 Apr 2013 11:09:02 -0700 (PDT), "langw...@fonz.dk" <langw...@fonz.dk>

at one point it did crash alot, but I haven't had many problems with
it for the
past few years



-Lasse

[Michael A. Terrell]

John Larkin wrote:
>
> DEC wrote operating systems (TOPS10, VMS, RSTS) that ran for months between
> power failures, time-sharing multiple, sometimes hostile, users. We are now in
> the dark ages of computing, overwhelmed by bloat and slop and complexity. No
> wonder people are buying tablets. DEC understood things that Intel and Microsoft
> never really got, like: don't execute data.

I've had Win2K run over nine months, between power failures that
lasted longer than the UPS batteries. DEC had more control over the
computers, and a tiny fraction of the number running Windows or Linux.


If DEC was so damned good, why were they unable to survive? Their
IBM 'clone' (Rainbow 100) was very overpriced, not compatible, and did a
very quick death spiral. Admit it. It was a dinosaur company with a
very tiny customer base.

[Michael A. Terrell]

John Larkin wrote:
>
> On Mon, 22 Apr 2013 00:07:47 +0300, upsid...@downunder.com wrote:
>
> >On Sun, 21 Apr 2013 13:22:12 -0700, John Larkin
> ><jjla...@highNOTlandTHIStechnologyPART.com> wrote:
> >
> >>
> >>DEC wrote operating systems (TOPS10, VMS, RSTS) that ran for months between
> >>power failures, time-sharing multiple, sometimes hostile, users.
> >
> >
> >I was responsible for some VMS-11 systems and I forgot to boot the
> >system every summer, when no-one was around. Booting the system the
> >system next year and everyone were happy :-).
> >
> >>We are now in
> >>the dark ages of computing, overwhelmed by bloat and slop and complexity. No
> >>wonder people are buying tablets. DEC understood things that Intel and Microsoft
> >>never really got, like: don't execute data.
> >
> >PDP-11/RSX-11M+ (early 1970's) had separate I/D spaces, VAX/VMS (mid
> >70's) had executable program sections.
>
> RSTS mapped code pages to be execute-only (apps couldn't write to code space)
> and data/stack pages were non-executable. Stack overflow and buffer overrun
> exploits were prevented by hardware. Both Intel and Microsoft were out of the
> mainstream of computing, which is why we have such a mess today.

Intel & Microsoft are the mainstream today, and DEC is in the
scrapyard of computing history.

[Allan Herriman]

On Sun, 21 Apr 2013 09:05:49 -0700, John Larkin wrote:

> The annoying thing is the CPU-to-FPGA interface. It takes a lot of FPGA
> pins and it tends to be async and slow. It would be great to have an
> industry-standard LVDS-type fast serial interface, with hooks like
> shared memory, but transparent and easy to use.

You've just described PCI Express.

- Industry standard fast serial interface.
- AC-coupled CML (rather than LVDS, but still differential).
- scalable bandwidth:
- 2.5, 5.0, 8.0 Gbps per lane.
- 1, 2, 4, 8 or 16 lanes.
- allows single access as well as bursts.
- multi-master (allows DMA).
- Fabric can be point-to-point (e.g. CPU-FPGA) or can use switches for
larger networks.
- in-band interrupts (saves pins).
- Peripherals (typically) just appear as chunks of memory in the CPU
address space.
- Widely supported by operating systems.
- Supports hot plug.
- Many FPGAs have hard cores for PCIe.
- Supported by ARM SoCs (but not the very cheapest ones).
- compatible with loads of off the shelf chips and cards.
- Easy to use (although that might be an "eye of the beholder" type of
thing).


I wouldn't recommend PCIe for the lowest cost or lowest power products,
but it's great for the stuff that I do.


Regards,
Allan

[John Larkin]

Tragically so. The thing that Intel and Microsoft had in common was brutal
rapaciousness. That often overcomes quality.

But Dec's PDP-11 bagat Unix, which begat Linux, then MacOS, then Android...

[John Larkin]

It was *the* minicomputer company and that changed the world.

[John Larkin]

On 22 Apr 2013 12:59:27 GMT, Allan Herriman <allanh...@hotmail.com> wrote:

>On Sun, 21 Apr 2013 09:05:49 -0700, John Larkin wrote:
>
>> The annoying thing is the CPU-to-FPGA interface. It takes a lot of FPGA
>> pins and it tends to be async and slow. It would be great to have an
>> industry-standard LVDS-type fast serial interface, with hooks like
>> shared memory, but transparent and easy to use.
>
>You've just described PCI Express.

No. PCIe is insanely complex and has horrible latency. It takes something like 2
microseconds to do an 8-bit read over gen1 4-lane PCIe. It was designed for
throughput, not latency.

We've done three PCIe projects so far, and it's the opposite of "transparent and
easy to use." The PCIe spec reads like the tax code and Obamacare combined.

Next up is Thunderbolt, probably worse.

>
>- Industry standard fast serial interface.
>- AC-coupled CML (rather than LVDS, but still differential).
>- scalable bandwidth:
>- 2.5, 5.0, 8.0 Gbps per lane.
>- 1, 2, 4, 8 or 16 lanes.
>- allows single access as well as bursts.
>- multi-master (allows DMA).
>- Fabric can be point-to-point (e.g. CPU-FPGA) or can use switches for
>larger networks.
>- in-band interrupts (saves pins).
>- Peripherals (typically) just appear as chunks of memory in the CPU
>address space.
>- Widely supported by operating systems.
>- Supports hot plug.
>- Many FPGAs have hard cores for PCIe.
>- Supported by ARM SoCs (but not the very cheapest ones).
>- compatible with loads of off the shelf chips and cards.
>- Easy to use (although that might be an "eye of the beholder" type of
>thing).
>
>
>I wouldn't recommend PCIe for the lowest cost or lowest power products,
>but it's great for the stuff that I do.
>
>
>Regards,
>Allan

[Allan Herriman]

On Mon, 22 Apr 2013 07:09:40 -0700, John Larkin wrote:

> On 22 Apr 2013 12:59:27 GMT, Allan Herriman <allanh...@hotmail.com>
> wrote:
>
>>On Sun, 21 Apr 2013 09:05:49 -0700, John Larkin wrote:
>>
>>> The annoying thing is the CPU-to-FPGA interface. It takes a lot of
>>> FPGA pins and it tends to be async and slow. It would be great to have
>>> an industry-standard LVDS-type fast serial interface, with hooks like
>>> shared memory, but transparent and easy to use.
>>
>>You've just described PCI Express.
>
> No. PCIe is insanely complex and has horrible latency. It takes
> something like 2 microseconds to do an 8-bit read over gen1 4-lane PCIe.
> It was designed for throughput, not latency.

I agree about it being designed for throughput, not latency. However,
with a fairly simple design, we can do 32 bit non-bursting reads or
writes in about 350ns over a single lane of gen 1 through 1 layer of
switching. I suspect there's some problem with your implementation
(unless your 2 microsecond figure was just hyperbole).

> We've done three PCIe projects so far, and it's the opposite of
> "transparent and easy to use." The PCIe spec reads like the tax code and
> Obamacare combined.

I found the spec clear. It's rather large though, and a text book serves
as more friendly introduction to the subject than the spec itself.

One of my co-workers was confused by the way addresses come most
significant octet first, whilst the data come least significant octet
first. It makes sense on a little endian machine, once you get over the
WTF.

Hot plug is the only thing that gives us headaches. PCIe Hot plug is
needed when reconfiguring the FPGA while the system is running.
OS support for hot plug is patchy.
Partial FPGA reconfiguration is one workaround (leaving the PCIe up while
reconfiguring the rest of the FPGA), although I haven't tried that in any
production design yet.

Regards,
Allan

[John Larkin]

On 22 Apr 2013 14:57:24 GMT, Allan Herriman <allanh...@hotmail.com> wrote:

>On Mon, 22 Apr 2013 07:09:40 -0700, John Larkin wrote:
>
>> On 22 Apr 2013 12:59:27 GMT, Allan Herriman <allanh...@hotmail.com>
>> wrote:
>>
>>>On Sun, 21 Apr 2013 09:05:49 -0700, John Larkin wrote:
>>>
>>>> The annoying thing is the CPU-to-FPGA interface. It takes a lot of
>>>> FPGA pins and it tends to be async and slow. It would be great to have
>>>> an industry-standard LVDS-type fast serial interface, with hooks like
>>>> shared memory, but transparent and easy to use.
>>>
>>>You've just described PCI Express.
>>
>> No. PCIe is insanely complex and has horrible latency. It takes
>> something like 2 microseconds to do an 8-bit read over gen1 4-lane PCIe.
>> It was designed for throughput, not latency.
>
>I agree about it being designed for throughput, not latency. However,
>with a fairly simple design, we can do 32 bit non-bursting reads or
>writes in about 350ns over a single lane of gen 1 through 1 layer of
>switching. I suspect there's some problem with your implementation
>(unless your 2 microsecond figure was just hyperbole).

Writes are relatively fast, ballpark 350 ns gen1/4lane. Reads are slow, around 2
us. That's from an x86 CPU into the PCIe hard core of an Altera FPGA, cabled
PCIe. A read requires two serial packets so is over twice the time of a write.

A random read or write from an embedded CPU, to, say, a DPM in an FPGA, really
should take tens of nanoseconds. We do parallel ARM-FPGA transfers with a klunky
async parallel interface in 100 ns or so, but it takes a lot of pins.

From an x86 (not that we'd ever use an Intel chip in an embedded app) we haven't
found any way to move more than 32 bits in a non-DMA PCIe read/write, even on a
64-bit CPU that has a few 128-bit MOVE opcodes.

>
>
>> We've done three PCIe projects so far, and it's the opposite of
>> "transparent and easy to use." The PCIe spec reads like the tax code and
>> Obamacare combined.
>
>I found the spec clear. It's rather large though, and a text book serves
>as more friendly introduction to the subject than the spec itself.
>
>One of my co-workers was confused by the way addresses come most
>significant octet first, whilst the data come least significant octet
>first. It makes sense on a little endian machine, once you get over the
>WTF.

Little-endian is evil, another legacy if Intel's clumsiness.

>
>Hot plug is the only thing that gives us headaches. PCIe Hot plug is
>needed when reconfiguring the FPGA while the system is running.
>OS support for hot plug is patchy.

We are still trying to get hot plug to work, both Linux and Windows. HELP!

[Allan Herriman]

I thought it was faster than that. If I remember, I'll measure some in
the lab tomorrow.

BTW, the write requires two packets as well.

>>Hot plug is the only thing that gives us headaches. PCIe Hot plug is
>>needed when reconfiguring the FPGA while the system is running.
>>OS support for hot plug is patchy.
>
> We are still trying to get hot plug to work, both Linux and Windows.
> HELP!

I don't know anything about hot plug support on Windows. On Linux,
however, there are two ways to do it:

- True hot plug. You need to use a switch (or root complex) that has
hardware support for the hot plug signals (particularly "Presence Detect"
that indicates a card is plugged in). The switch turns these into
special messages that get sent back to the RC, and the OS should honour
these and do the right thing. This should work on Windows too, as it's
part of the standard.

- Fake hot plug. With the Linux "fakephp" driver you can fake the hot
plug messages if you don't have hardware support for them. This isn't
supported in all kernel versions though. Read more here:
http://scaryreasoner.wordpress.com/2012/01/26/messing-around-with-linux-
pci-hotplug/

In both cases there can be address space fragmentation that can stop the
system from working. By that I mean that the OS can't predict what will
be plugged in, so it can't know to reserve a contiguous chunk of address
space for your FPGA. The OS may do something stupid like put your
soundcard right in the middle of the space you wanted. Grrr.

Recent versions of the Linux kernel allow you to specify rules regarding
address allocation to avoid the fragmentation problem, but I've never
used them and I'm not a kernel hacker, so I don't know anything about
that.

Regards,
Allan

[John Larkin]

Does it? Writes are buffered and there is some token-quota mechanism that lets
writes blast away, and there may be a "back off, Sam!" reply packet now and then
if the target can't keep up. If the target is fast, like a RAM or something,
that won't happen, and writes are packet limited in one direction. Probably.

>
>
>
>>>Hot plug is the only thing that gives us headaches. PCIe Hot plug is
>>>needed when reconfiguring the FPGA while the system is running.
>>>OS support for hot plug is patchy.
>>
>> We are still trying to get hot plug to work, both Linux and Windows.
>> HELP!
>
>
>I don't know anything about hot plug support on Windows. On Linux,
>however, there are two ways to do it:
>
>- True hot plug. You need to use a switch (or root complex) that has
>hardware support for the hot plug signals (particularly "Presence Detect"
>that indicates a card is plugged in). The switch turns these into
>special messages that get sent back to the RC, and the OS should honour
>these and do the right thing. This should work on Windows too, as it's
>part of the standard.

Yeah, Microsoft lives to honor standards.

>
>- Fake hot plug. With the Linux "fakephp" driver you can fake the hot
>plug messages if you don't have hardware support for them. This isn't
>supported in all kernel versions though. Read more here:
>http://scaryreasoner.wordpress.com/2012/01/26/messing-around-with-linux-
>pci-hotplug/
>
>In both cases there can be address space fragmentation that can stop the
>system from working. By that I mean that the OS can't predict what will
>be plugged in, so it can't know to reserve a contiguous chunk of address
>space for your FPGA. The OS may do something stupid like put your
>soundcard right in the middle of the space you wanted. Grrr.

We're assuming that an application will crash if its memory-mapped target region
(in our case, the remapped VME bus) vanishes. What we can't do so far under
Linux is re-enumerate the PCI space and start things back up without rebooting.
We're still working on it. We have implemented all the optocoupled sideband
signals for hot plug, and training packets resume after we reconnect. We're
still working on it.

[upsid...@downunder.com]

On Sun, 21 Apr 2013 14:12:05 -0700, John Larkin
<jjla...@highNOTlandTHIStechnologyPART.com> wrote:

>On Sun, 21 Apr 2013 16:40:22 -0400, rickman <gnu...@gmail.com> wrote:
>
>>On 4/21/2013 4:22 PM, John Larkin wrote:
>>> On Sun, 21 Apr 2013 17:34:12 GMT, Ralph Barone<addre...@invalid.invalid>
>>> wrote:
>>>>
>>>> and end up doing making new and innovative mistakes (just channeling Murphy
>>>> here).
>>>
>>> DEC wrote operating systems (TOPS10, VMS, RSTS) that ran for months between
>>> power failures, time-sharing multiple, sometimes hostile, users. We are now in
>>> the dark ages of computing, overwhelmed by bloat and slop and complexity. No
>>> wonder people are buying tablets. DEC understood things that Intel and Microsoft
>>> never really got, like: don't execute data.
>>
>>You really should stick to things you understand. Every Intel processor
>>since the 8086 has included protection mechanism to prevent the
>>execution of data. But they have to be used properly... Blame
>>Microsoft and all the other software vendors, but don't blame Intel.
>
>The Intel memory protection is primitive.

The 8086 had execute privileges on the segment register level and thus
comparable to PDP-11 with eight up to 8 KiB segments with different
protection attributes.

With 80386 and some sort of virtual memory support, unfortunately
Intel forgot to include the exe/noexe bit in each page table entry (as
in VAX/VMS), but still relied on the segment register protection bits.

[Tauno Voipio]

The first Intel family member to have segment-based protection was
80286, neither 8086 nor 80186.

There is certain sense in Intel's policy: segmentation is for protection
and paging for virtual mempry under it.

--

Tauno Voipio

[lang...@fonz.dk]

On Apr 22, 5:16 pm, John Larkin
<jjlar...@highNOTlandTHIStechnologyPART.com> wrote:

> On 22 Apr 2013 14:57:24 GMT, Allan Herriman <allanherri...@hotmail.com> wrote:
>
>
>
>
>
>
>
>
>
> >On Mon, 22 Apr 2013 07:09:40 -0700, John Larkin wrote:
>

> >> On 22 Apr 2013 12:59:27 GMT, Allan Herriman <allanherri...@hotmail.com>

why is it any more or less evil than big endian?

-Lasse

[upsid...@downunder.com]

On Mon, 22 Apr 2013 23:19:50 +0300, Tauno Voipio
<tauno....@notused.fi.invalid> wrote:


>The first Intel family member to have segment-based protection was
>80286, neither 8086 nor 80186.

I have actively tried to forget that I idid some satellite image and
planeratory probe image analyzing using an i286 machine with a 10 MHz
clock :-)

[John Larkin]

On Mon, 22 Apr 2013 13:37:21 -0700 (PDT), "lang...@fonz.dk"
<lang...@fonz.dk> wrote:

>>
>> Little-endian is evil, another legacy if Intel's clumsiness.
>>
>
>why is it any more or less evil than big endian?
>
>-Lasse

!sdrawkcab s'ti esuaceB


--

John Larkin Highland Technology, Inc

jlarkin at highlandtechnology dot com

http://www.highlandtechnology.com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators

Custom laser drivers and controllers

Photonics and fiberoptic TTL data links

VME thermocouple, LVDT, synchro acquisition and simulation

[Nico Coesel]

John Larkin <jjla...@highNOTlandTHIStechnologyPART.com> wrote:

>On Sun, 21 Apr 2013 08:23:37 -0500, Vladimir Vassilevsky <nos...@nowhere.com>
>wrote:
>
>>On 4/20/2013 5:42 PM, rickman wrote:
>>> I have been working on designs of processors for FPGAs for quite a
>>> while. I have looked at the uBlaze, the picoBlaze, the NIOS, two from
>>> Lattice and any number of open source processors. Many of the open
>>> source designs were stack processors since they tend to be small and
>>> efficient in an FPGA. J1 is one I had pretty much missed until lately.
>>> It is fast and small and looks like it wasn't too hard to design
>>> (although looks may be deceptive), I'm impressed. There is also the b16
>>> from Bernd Paysan, the uCore, the ZPU and many others.
>>>
>>> Lately I have been looking at a hybrid approach which combines features
>>> of addressing registers in order to access parameters of a stack CPU. It
>>> looks interesting.
>>>
>>> Anyone else here doing processor designs on FPGAs?
>>>
>>
>>Soft core is fun thing to do, but otherwise I see no use.
>>Except for very few special applications, standalone processor is better
>>then FPGA soft core in every point, especially the price.

Most entry level scopes consist of an FPGA running a soft processor.

>The annoying thing is the CPU-to-FPGA interface. It takes a lot of FPGA pins and
>it tends to be async and slow. It would be great to have an industry-standard
>LVDS-type fast serial interface, with hooks like shared memory, but transparent
>and easy to use.

You mean PCI express? :-)

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

[Allan Herriman]

On Mon, 22 Apr 2013 09:27:04 -0700, John Larkin wrote:

[ snip pcie hot plug discussion ]

> We're assuming that an application will crash if its memory-mapped
> target region (in our case, the remapped VME bus) vanishes. What we
> can't do so far under Linux is re-enumerate the PCI space and start
> things back up without rebooting.

With fakephp, you should just need to rescan that slot. With proper hot
swap hardware support, it should just happen automatically. (As if
anything would go wrong with that!)

When the hot plug removal event happens, the OS is meant to unload the
drivers.

The drivers get reloaded after the hot plug insertion event. Possibly
not the same drivers as before, if the FPGA contains something else.

Your higher level application needs to be aware that the driver can come
and go with the hot plug events. You'll need some sort of mechanism to
inform the application (e.g. a signal).
Presumably the application is the actual cause of the FPGA
reconfiguration, in which case it knows when the FPGA is there or not and
doesn't need to be told.

> We're still working on it. We have
> implemented all the optocoupled sideband signals for hot plug, and
> training packets resume after we reconnect. We're still working on it.

I found that just the presence detect was needed for reliable hot plug.
All the others are optional.

Regards,
Allan

[Michael A. Terrell]

John Larkin wrote:
>
> On Mon, 22 Apr 2013 07:49:11 -0400, "Michael A. Terrell"
> <mike.t...@earthlink.net> wrote:
>
> >
> >John Larkin wrote:
> >>
> >> DEC wrote operating systems (TOPS10, VMS, RSTS) that ran for months between
> >> power failures, time-sharing multiple, sometimes hostile, users. We are now in
> >> the dark ages of computing, overwhelmed by bloat and slop and complexity. No
> >> wonder people are buying tablets. DEC understood things that Intel and Microsoft
> >> never really got, like: don't execute data.
> >
> >
> > I've had Win2K run over nine months, between power failures that
> >lasted longer than the UPS batteries. DEC had more control over the
> >computers, and a tiny fraction of the number running Windows or Linux.
> >
> >
> > If DEC was so damned good, why were they unable to survive? Their
> >IBM 'clone' (Rainbow 100) was very overpriced, not compatible, and did a
> >very quick death spiral. Admit it. It was a dinosaur company with a
> >very tiny customer base.
>
> It was *the* minicomputer company and that changed the world.

Really? Could it have handled any modern application, let alone
dozens or hundreds of them at once.

[Michael A. Terrell]

John Larkin wrote:
>
> On 22 Apr 2013 12:59:27 GMT, Allan Herriman <allanh...@hotmail.com> wrote:
>
> >On Sun, 21 Apr 2013 09:05:49 -0700, John Larkin wrote:
> >
> >> The annoying thing is the CPU-to-FPGA interface. It takes a lot of FPGA
> >> pins and it tends to be async and slow. It would be great to have an
> >> industry-standard LVDS-type fast serial interface, with hooks like
> >> shared memory, but transparent and easy to use.
> >
> >You've just described PCI Express.
>
> No. PCIe is insanely complex and has horrible latency. It takes something like 2
> microseconds to do an 8-bit read over gen1 4-lane PCIe. It was designed for
> throughput, not latency.
>
> We've done three PCIe projects so far, and it's the opposite of "transparent and
> easy to use." The PCIe spec reads like the tax code and Obamacare combined.
>
> Next up is Thunderbolt, probably worse.

Have you ever worked with PCI-X?

[Allan Herriman]

I looked at a trace on a board at work. I was surprised - the writes
were fast(ish) - about 100 ns was the smallest gap I saw between writes.
The reads were slower. I didn't see reads closer together than about 2us.

This seems consistent with Larkin's measurements.

I'm still surprised though - 2 us is 20000 bit times on a 4 lane gen 1.
Ok, it's only 16000 bit times before the 8B10B coding.

Maybe the switch is configured for store-and-forward rather than cut
through, or something equally silly.


Regards,
Allan

[John Larkin]

On Tue, 23 Apr 2013 02:48:53 -0400, "Michael A. Terrell"

As I recall, Unix and C were invented for the PDP11. As was Arpanet and the
Internet. The PDP8 was the first "personal" computer, a computer that one person
could buy and use all by himself, to automate a lab experiment or (in my case)
simulate a steamship power train. That changed everything.

DECs RT11 OS was cloned to become CPM and Microsoft DOS, and lives on in the
Windows command line.

What sort of computing system did you have in 1969? I had a PDP8 running Focal.
What did you compute on in 1975? I had a PDP11 timeshare system with around 20
users.

[John Larkin]

Yup, PCIe is a pig! It's OK if you do DMA, but there's a heap of overhead
building descriptor chains and fielding interrupts and stuff.

We're writing a Linux driver that lets us build descriptor chains and keep them,
and reuse them as needed to repeat data transfers.

[John Larkin]

No, but it's mostly dead, as PCI will soon be. Intel busses only last a few
years each.

[Bill Martin]

On 04/22/2013 07:03 AM, John Larkin wrote:

>> Intel & Microsoft are the mainstream today, and DEC is in the
>> scrapyard of computing history.
>
> Tragically so. The thing that Intel and Microsoft had in common was brutal
> rapaciousness. That often overcomes quality.
>
> But Dec's PDP-11 bagat Unix, which begat Linux, then MacOS, then Android...
>
>

Bell Labs begat Unix, Ken Olson considered Unix "Snake Oil", didn't want
anything to do with it.
-bill

[John Larkin]

On Tue, 23 Apr 2013 13:46:55 -0700, Bill Martin <w...@wwmartin.net>
wrote:

But C and Unix were developed on the PDP11. Unix was "born" in 1970,
on a PDP11/20. C is practically a PDP11 assembler.

>-bill

KO made a lot of mistakes. But DECs architectures - PDP11, VAX, Alpha
- were great. And their operating systems were excellent. It's
unfortunate that the winners were Microsoft and Intel.

--

John Larkin Highland Technology, Inc

jlarkin at highlandtechnology dot com

http://www.highlandtechnology.com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators

Custom laser drivers and controllers

Photonics and fiberoptic TTL data links

[Bill Sloman]

On Tuesday, 23 April 2013 23:59:05 UTC+10, John Larkin wrote:
> On Tue, 23 Apr 2013 02:48:53 -0400, "Michael A. Terrell"
> <mike.t...@earthlink.net> wrote:
> >John Larkin wrote:
> >> On Mon, 22 Apr 2013 07:49:11 -0400, "Michael A. Terrell"
> >> <mike.t...@earthlink.net> wrote:
> >> >John Larkin wrote:
> >> >>
> >> >> DEC wrote operating systems (TOPS10, VMS, RSTS) that ran for months
> >> >> between power failures, time-sharing multiple, sometimes hostile,
> >> >> users. We are now in the dark ages of computing, overwhelmed by bloat
> >> >> and slop and complexity. No wonder people are buying tablets. DEC

> >> >> understood things that Intel and Microsoftnever really got, like: don't > >> >> execute data.

> >> >
> >> > I've had Win2K run over nine months, between power failures that
> >> >lasted longer than the UPS batteries. DEC had more control over the
> >> >computers, and a tiny fraction of the number running Windows or Linux.
> >> >
> >> > If DEC was so damned good, why were they unable to survive? Their
> >> >IBM 'clone' (Rainbow 100) was very overpriced, not compatible, and did a
> >> >very quick death spiral. Admit it. It was a dinosaur company with a
> >> >very tiny customer base.
> >>
> >> It was *the* minicomputer company and that changed the world.
> >
> > Really? Could it have handled any modern application, let alone
> >dozens or hundreds of them at once.
>
> As I recall, Unix and C were invented for the PDP11. As was Arpanet and the
> Internet. The PDP8 was the first "personal" computer, a computer that one
> person could buy and use all by himself, to automate a lab experiment or (in

> my case) to simulate a steamship power train. That changed everything.

>
> DECs RT11 OS was cloned to become CPM and Microsoft DOS, and lives on in the
> Windows command line.
>
> What sort of computing system did you have in 1969? I had a PDP8 running
> Focal.
>
> What did you compute on in 1975? I had a PDP11 timeshare system with around
> 20 users.

I had access to a PDP-8 in 1968. It ran Focal, but I programmed it in it's assembly language - Macro-8 - so I could set up and interrupt-driven program to monitor and document the chemical reaction I was researching.

I crunched the - more or less - raw numbers I got from the PDP-8 (it did selective data averaging, but no more) on an IBM 7040/44. The PDP-8 numbers came out on paper tape, and went through a tape-to-Hollerith card converter before they got onto the IBM machine, which I programmed in Fortran, and got to run as a single user machine for hours in the middle of the night - usually 2:00am to 6:00am.

In my first industrial job, I had remote access to a Control Data machine running Fortran from an ASR-33 teletype terminal, but after that it was mostly DEC.

IRRR DEC failed because it didn't take personal computers seriously, rather like the railway companies who thought that they were in the railway business when they were actually in the transportation business.

--
Bill Sloman, Sydney

[rickman]

On 4/23/2013 5:58 PM, John Larkin wrote:
> On Tue, 23 Apr 2013 13:46:55 -0700, Bill Martin<w...@wwmartin.net>
> wrote:
>
>> On 04/22/2013 07:03 AM, John Larkin wrote:
>>

>>>> Intel& Microsoft are the mainstream today, and DEC is in the

>>>> scrapyard of computing history.
>>>
>>> Tragically so. The thing that Intel and Microsoft had in common was brutal
>>> rapaciousness. That often overcomes quality.
>>>
>>> But Dec's PDP-11 bagat Unix, which begat Linux, then MacOS, then Android...
>>>
>>>
>> Bell Labs begat Unix, Ken Olson considered Unix "Snake Oil", didn't want
>> anything to do with it.
>
> But C and Unix were developed on the PDP11. Unix was "born" in 1970,
> on a PDP11/20. C is practically a PDP11 assembler.
>
>> -bill
>
> KO made a lot of mistakes. But DECs architectures - PDP11, VAX, Alpha
> - were great. And their operating systems were excellent. It's
> unfortunate that the winners were Microsoft and Intel.

"Unfortunate"... KO made the humongously large mega-mistake of thinking
there was no need for personal computers. But to his credit at that
time computers were a bit larger than they are now. I think there was
an ad of a beautiful woman in late 60's attire, perhaps rather elegant
attire, but in a kitchen standing by a decwriter printing something.
Not quite the ticket for storing recipes really.

Bill, on the other hand only made two mistakes. The first was thinking
there would never be a need for more than 640 kB of computer memory. He
got over that one pretty quickly since he wasn't designing hardware.
But then he seems to have felt the Internet was not something important
to a company writing computer OS. lol They saw the winds blowing a
different direction and had to change their rigging all the way into
court to justify why they were trying to kick other browsers off "their"
computers.

Who else made fatal mistakes were made in the computer industry? Who at
Osborn decided to promote the next generation before they were ready to
ship and killed the current sales?

Why did the Alpha die? Was that more an issue of DEC going away? I
don't recall who ended up with it. Was it Intel who let it die a
lingering death?

--

Rick

[rickman]

On 4/23/2013 10:03 AM, John Larkin wrote:
> On Tue, 23 Apr 2013 02:50:10 -0400, "Michael A. Terrell"
> <mike.t...@earthlink.net> wrote:
>
>>
>> John Larkin wrote:
>>>
>>> On 22 Apr 2013 12:59:27 GMT, Allan Herriman<allanh...@hotmail.com> wrote:
>>>
>>>> On Sun, 21 Apr 2013 09:05:49 -0700, John Larkin wrote:
>>>>
>>>>> The annoying thing is the CPU-to-FPGA interface. It takes a lot of FPGA
>>>>> pins and it tends to be async and slow. It would be great to have an
>>>>> industry-standard LVDS-type fast serial interface, with hooks like
>>>>> shared memory, but transparent and easy to use.
>>>>
>>>> You've just described PCI Express.
>>>
>>> No. PCIe is insanely complex and has horrible latency. It takes something like 2
>>> microseconds to do an 8-bit read over gen1 4-lane PCIe. It was designed for
>>> throughput, not latency.
>>>
>>> We've done three PCIe projects so far, and it's the opposite of "transparent and
>>> easy to use." The PCIe spec reads like the tax code and Obamacare combined.
>>>
>>> Next up is Thunderbolt, probably worse.
>>
>>
>> Have you ever worked with PCI-X?
>
> No, but it's mostly dead, as PCI will soon be. Intel busses only last a few
> years each.

A *few* years? PCI has been around for 20 years!

--

Rick

[John Larkin]

But mobos seldom have PCI slots any more. It's all PCIe now. And
Thunderbolt will displace PCIe.

Motherboard slots are going away. Hell, motherboards are going away!

--

John Larkin Highland Technology, Inc

jlarkin at highlandtechnology dot com

http://www.highlandtechnology.com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators

Custom laser drivers and controllers

Photonics and fiberoptic TTL data links

[Michael A. Terrell]

CP/M<>DOS and never was. 'Control Program for Microcomputers' was
written by Gary Kildall of Digital Research, Inc, and the later MP/M for
multiple users was written for the 8080 from scratch. If that is a
clone, so is every other OS.

> What sort of computing system did you have in 1969? I had a PDP8 running Focal.

Did you own it?

> What did you compute on in 1975? I had a PDP11 timeshare system with around 20
> users.

I was still in high school in 1969, but a few students at the OTHER
high school got some time on an IBM 360 that belonged to a local bank.
I got my first computer in 1983, but I was troubleshooting & repairing
the boards & software for a pair of Exorcisor bus based 'Metrodata'
computers with six NTSC video outputs per system before I owned a
computer. I had to repair them, since the OEM was out of business. A
whopping 48 KB of RAM, and one 6800 MPU per system. One system had a
SMS dual 8" floppy disk drive system, and they shared a single TI
computer terminal. I wrote a terminal program for a Commodore 64 to
replace the flaky TI, and added a menu system to reduce the 100+
commands the operator had to use to access different functions.

[Michael A. Terrell]

John Larkin wrote:
>
> On Tue, 23 Apr 2013 02:50:10 -0400, "Michael A. Terrell"
> <mike.t...@earthlink.net> wrote:
>
> >
> >John Larkin wrote:
> >>
> >> On 22 Apr 2013 12:59:27 GMT, Allan Herriman <allanh...@hotmail.com> wrote:
> >>
> >> >On Sun, 21 Apr 2013 09:05:49 -0700, John Larkin wrote:
> >> >
> >> >> The annoying thing is the CPU-to-FPGA interface. It takes a lot of FPGA
> >> >> pins and it tends to be async and slow. It would be great to have an
> >> >> industry-standard LVDS-type fast serial interface, with hooks like
> >> >> shared memory, but transparent and easy to use.
> >> >
> >> >You've just described PCI Express.
> >>
> >> No. PCIe is insanely complex and has horrible latency. It takes something like 2
> >> microseconds to do an 8-bit read over gen1 4-lane PCIe. It was designed for
> >> throughput, not latency.
> >>
> >> We've done three PCIe projects so far, and it's the opposite of "transparent and
> >> easy to use." The PCIe spec reads like the tax code and Obamacare combined.
> >>
> >> Next up is Thunderbolt, probably worse.
> >
> >
> > Have you ever worked with PCI-X?
>
> No, but it's mostly dead, as PCI will soon be. Intel busses only last a few
> years each.

It's alive & well in real servers for their RAID controllers and
Ethernet or FC ports. I've never seen it used in a computer that sold
for under $3K.

[John Larkin]

On Tue, 23 Apr 2013 22:38:23 -0400, "Michael A. Terrell"

No, but my employer bought it for me; cost $12,800 with 4k 12-bit words of core
and a teletype, when you could but a Chevy for a tenth of that. It was mine in
the sense that I was the main, usually only, user. A couple of years later, 1972
I think, we got one of the first PDP-11s. The PDP-11 was a wonderful
architecture; it taught a lot of people, including me, how to think. x86 is a
pig by comparison.

[John Larkin]

On Tue, 23 Apr 2013 22:40:51 -0400, "Michael A. Terrell"

Do current Intel chip sets support PCI-X? Or even PCI?

[DecadentLinuxUserNumeroUno]

I think PCI was a *just* hard intermediary bus. All the other busses
were tertiary to it, and went though it to get to the CPU.

I think PCIe is a hard intermediary bus too but it has it's own API
practically, and I would call that pretty advanced. PCI-X is likely
fully superseded by e, but elements of the original PCI paradigm
decidedly must remain. PCI only had about 11 command codes.

[Jasen Betts]

On 2013-04-23, rickman <gnu...@gmail.com> wrote:

> Who else made fatal mistakes were made in the computer industry? Who at
> Osborn decided to promote the next generation before they were ready to
> ship and killed the current sales?
>
> Why did the Alpha die? Was that more an issue of DEC going away? I
> don't recall who ended up with it.
> Was it Intel who let it die a lingering death?

HP http://h18002.www1.hp.com/alphaserver


--
⚂⚃ 100% natural

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[John Larkin]

PCIe was desiged to be totally transparent against PCI. In theory, a BIOS or a
driver can't tell if its talking to PCI or to PCIe. Thunderbolt is supposed to
be the same. The only differences may be the hot-plug provisions.

[rickman]

On 4/24/2013 5:19 AM, Jasen Betts wrote:
> On 2013-04-23, rickman<gnu...@gmail.com> wrote:
>
>> Who else made fatal mistakes were made in the computer industry? Who at
>> Osborn decided to promote the next generation before they were ready to
>> ship and killed the current sales?
>>
>> Why did the Alpha die? Was that more an issue of DEC going away? I
>> don't recall who ended up with it.
>> Was it Intel who let it die a lingering death?
>
> HP http://h18002.www1.hp.com/alphaserver

Ah, it was HP who ended up with it. It lasted up until 2008, that's not
too bad really.

--

Rick

[rickman]

On 4/23/2013 8:14 PM, John Larkin wrote:
> On Tue, 23 Apr 2013 19:45:07 -0400, rickman<gnu...@gmail.com> wrote:
>
>> On 4/23/2013 10:03 AM, John Larkin wrote:
>>>
>>> No, but it's mostly dead, as PCI will soon be. Intel busses only last a few
>>> years each.
>>
>> A *few* years? PCI has been around for 20 years!
>
> But mobos seldom have PCI slots any more. It's all PCIe now. And
> Thunderbolt will displace PCIe.
>
> Motherboard slots are going away. Hell, motherboards are going away!

Sure, for that matter PCs are going away for the mainstream. In 10
years it will literally be like working on the Enterprise... the space
ship Enterprise. Everyone will be using tablets and pads, there just
won't be a need for the traditional PC except for specialties... like
PCB layout, lol

There won't be any busses really. It will all be wireless. Maybe it
will all be powered by a Tesla type power source too. lol

That doesn't change the fact that PCI was mainstream for well over a
decade, more like 15 years!

BTW, are you capable of learning? Or have you reached your learning
capacity?

--

Rick

[Robert Baer]

What the hell is wrong with PARALLEL?
You get the _whole_ byte/word/whatever each possible I/O cycle and do
not have to wait 20+ cycles for preamble bits, 16 data bits, stop bits
(maybe more for stupid "framing" because designer was too lazy to
enforce assumptions that would speed things up).

[Robert Baer]

lang...@fonz.dk wrote:
> On Apr 22, 5:16 pm, John Larkin
> <jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
>> On 22 Apr 2013 14:57:24 GMT, Allan Herriman<allanherri...@hotmail.com> wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On Mon, 22 Apr 2013 07:09:40 -0700, John Larkin wrote:
>>
>>>> On 22 Apr 2013 12:59:27 GMT, Allan Herriman<allanherri...@hotmail.com>

>>>> wrote:
>>
>>>>> On Sun, 21 Apr 2013 09:05:49 -0700, John Larkin wrote:
>>

>>>>>> The annoying thing is the CPU-to-FPGA interface. It takes a lot of
>>>>>> FPGA pins and it tends to be async and slow. It would be great to have
>>>>>> an industry-standard LVDS-type fast serial interface, with hooks like
>>>>>> shared memory, but transparent and easy to use.
>>

>>>>> You've just described PCI Express.
>>
>>>> No. PCIe is insanely complex and has horrible latency. It takes
>>>> something like 2 microseconds to do an 8-bit read over gen1 4-lane PCIe.
>>>> It was designed for throughput, not latency.
>>

>>> I agree about it being designed for throughput, not latency. However,
>>> with a fairly simple design, we can do 32 bit non-bursting reads or
>>> writes in about 350ns over a single lane of gen 1 through 1 layer of
>>> switching. I suspect there's some problem with your implementation
>>> (unless your 2 microsecond figure was just hyperbole).
>>
>> Writes are relatively fast, ballpark 350 ns gen1/4lane. Reads are slow, around 2
>> us. That's from an x86 CPU into the PCIe hard core of an Altera FPGA, cabled
>> PCIe. A read requires two serial packets so is over twice the time of a write.
>>

>> A random read or write from an embedded CPU, to, say, a DPM in an FPGA, really
>> should take tens of nanoseconds. We do parallel ARM-FPGA transfers with a klunky
>> async parallel interface in 100 ns or so, but it takes a lot of pins.
>>
>> From an x86 (not that we'd ever use an Intel chip in an embedded app) we haven't
>> found any way to move more than 32 bits in a non-DMA PCIe read/write, even on a
>> 64-bit CPU that has a few 128-bit MOVE opcodes.

>>
>>
>>
>>>> We've done three PCIe projects so far, and it's the opposite of
>>>> "transparent and easy to use." The PCIe spec reads like the tax code and
>>>> Obamacare combined.
>>

>>> I found the spec clear. It's rather large though, and a text book serves
>>> as more friendly introduction to the subject than the spec itself.
>>
>>> One of my co-workers was confused by the way addresses come most
>>> significant octet first, whilst the data come least significant octet
>>> first. It makes sense on a little endian machine, once you get over the
>>> WTF.

>>
>> Little-endian is evil, another legacy if Intel's clumsiness.
>>
>
> why is it any more or less evil than big endian?
>
> -Lasse

Just give me his feather headband..

[John Larkin]

This week's project is to learn all about synchros, resolvers, control
transformers, and the many other related critters, and to figure out the
conventions, voltages, phases, and the trig for acquiring and simulating all of
that stuff.

I did win a burger and a beer. I guessed that the GCC atan2 function would take
about 10 us on our ARM processor, and Rob bet it would take one. He wanted to
bet based on 5.5 as the cut point, but I suggested that the geometric mean was
more fair. Ok, it takes just about 4 us, so I won by about 800 ns.
Now he wants to hack the source code to eliminate some paths we don't need, like
the checks for infinity and NAN and such, and speed it up. That would be a lot
of work for a burger and a beer.

And I'm about to learn a lot about kilowatt bar lasers, preferably without
losing any important body parts.

--

John Larkin Highland Technology Inc

www.highlandtechnology.com jlarkin at highlandtechnology dot com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators

Custom timing and laser controllers

Photonics and fiberoptic TTL data links

[Michael A. Terrell]

Yet the PDP-11s have all been scrapped. I scrapped a lot of them in
the early '90s. Tractor trailer loads of off lease CAD systems.

[John Larkin]

On Thu, 25 Apr 2013 00:10:17 -0400, "Michael A. Terrell"

Sure. There's not a lot of demand for fractional-mips computers with kilobyte
core memories. Lots of Univacs, Crays, GE, and IBM PC-XT computers have been
scrapped too.

[Michael A. Terrell]

Ask Intel.

Dell still sells a bunch of expensive PCI-X cards, and they are quick
to drop items like that if the market drops. Some of the cards are
$1800.

A lot of external drive arrays for server farms use Fiber Channel
PCI-X interface cards.

[Robert Baer]

Yeah, for the PDP-11, designing specialized interface boards and
programming for them was very nice and straight-forward.

[upsid...@downunder.com]

On Wed, 24 Apr 2013 13:15:12 -0800, Robert Baer
<rober...@localnet.com> wrote:

>> Most entry level scopes consist of an FPGA running a soft processor.
>>
>>> The annoying thing is the CPU-to-FPGA interface. It takes a lot of FPGA pins and
>>> it tends to be async and slow. It would be great to have an industry-standard
>>> LVDS-type fast serial interface, with hooks like shared memory, but transparent
>>> and easy to use.
>>
>> You mean PCI express? :-)
>>
> What the hell is wrong with PARALLEL?
> You get the _whole_ byte/word/whatever each possible I/O cycle and do
>not have to wait 20+ cycles for preamble bits, 16 data bits, stop bits
>(maybe more for stupid "framing" because designer was too lazy to
>enforce assumptions that would speed things up).

The real problem with parallel channels is that the length
(propagation delay) of each channel must be the same.

In the 1970's with 1/2 inch magnetic tapes, the 1600 BPI tapes were
much easier to read, since each channel was self-clocked.

However, in order to read 800 BPI (non-self-clocked) tapes written on
a foreign tape drive, you had to use a screw driver to adjust the read
head azimuth angle, to compensate for the skew at different bit
channels.

[John Larkin]

The 11 had no i/o instructions, which was cool. Devices were memory
mapped, so no opcodes were wasted on klunky IN and OUT instructions,
and any memory opcode could operate on i/o, too. 68K worked like that,
too. The 68K was just a better PDP-11.

The PDP-11 was programmed in octal, and with a little practice you
could assemble instruction in your head and map them directly into
octal. I can still do some.

MOVB (r1)+, R5 is (I think) 112105 octal.

--

John Larkin Highland Technology, Inc

jlarkin at highlandtechnology dot com

http://www.highlandtechnology.com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators

Custom laser drivers and controllers

Photonics and fiberoptic TTL data links

[John Larkin]

On Thu, 25 Apr 2013 00:54:32 -0400, "Michael A. Terrell"

The last time I tried to ask Intel anything [1], they insisted that I
be certified first. That involved furnishing all sorts of company info
and presenting a plan that proved we would build at least 10K systems
the first year. All that to get a datasheet!

Go ARM!

[1] info about Thunderbolt bridge chips

--

John Larkin Highland Technology, Inc

jlarkin at highlandtechnology dot com

http://www.highlandtechnology.com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators

Custom laser drivers and controllers

Photonics and fiberoptic TTL data links

[rickman]

On 4/25/2013 12:21 AM, John Larkin wrote:
> On Thu, 25 Apr 2013 00:10:17 -0400, "Michael A. Terrell"
> <mike.t...@earthlink.net> wrote:
>>
>> Yet the PDP-11s have all been scrapped.
>
> Sure. There's not a lot of demand for fractional-mips computers with kilobyte
> core memories. Lots of Univacs, Crays, GE, and IBM PC-XT computers have been
> scrapped too.

Actually there is a huge demand for such processors, and smaller. Do
you wear a digital watch? What's in your microwave, your TV remote,
ect... DEC's problem was they didn't know how to package.

BTW, learn to trim your posts...

--

Rick

[rickman]

You just can't learn to trim your posts, no matter what. Did you ever
see the movie Memento? Maybe we need to get you a tattoo?

I bet if you reply to this post it is trimmed. lol

--

Rick

[lang...@fonz.dk]

On Apr 26, 8:04 pm, John Larkin <jlar...@highlandtechnology.com>
wrote:

> On Wed, 24 Apr 2013 22:33:32 -0800, Robert Baer
>
>
>
>
>
>
>
>
>
> <robertb...@localnet.com> wrote:
> >Michael A. Terrell wrote:
>
> >> John Larkin wrote:
>
> >>> On Tue, 23 Apr 2013 22:38:23 -0400, "Michael A. Terrell"

> >>> <mike.terr...@earthlink.net>  wrote:

>
> >>>> John Larkin wrote:
>
> >>>>> On Tue, 23 Apr 2013 02:48:53 -0400, "Michael A. Terrell"

> >>>>> <mike.terr...@earthlink.net>  wrote:

>
> >>>>>> John Larkin wrote:
>
> >>>>>>> On Mon, 22 Apr 2013 07:49:11 -0400, "Michael A. Terrell"

> >>>>>>> <mike.terr...@earthlink.net>  wrote:

with IO instructions you don't need to do a whole lot of address
decoding
for if you need a few IO registers, you can easily make io a different
speed
than memory, if the opcode aren't used for anything else they are not
wasted

And nothing prevents you from memory mapping devices instead of using
the
IO instructions


-Lasse

[upsid...@downunder.com]

On Fri, 26 Apr 2013 11:26:39 -0700 (PDT), "lang...@fonz.dk"
<lang...@fonz.dk> wrote:

>On Apr 26, 8:04�pm, John Larkin <jlar...@highlandtechnology.com>
>wrote:

>> The 11 had no i/o instructions, which was cool. Devices were memory
>> mapped, so no opcodes were wasted on klunky IN and OUT instructions,
>> and any memory opcode could operate on i/o, too. 68K worked like that,
>> too. The 68K was just a better PDP-11.
>>
>
>with IO instructions you don't need to do a whole lot of address
>decoding
>for if you need a few IO registers, you can easily make io a different
>speed
>than memory, if the opcode aren't used for anything else they are not
>wasted

The PDP-11 allocated 8 KiB for the I/O page. This was of course much
if you only had 64 KiB address space (no MMU), not so bad with 256 KiB
logical address space (such as PDP11/34) and insignificant in the 4
MiB address space (such as PDP11/70).

With 8 KiB I/O page, it was not a problem to allocate register space
for a large number of Unibus/QBUS cards, each peripheral register
could have its own address in the I/O page.

Compare this to some processors with specialized I/O instructions with
perhaps up to 256 I/O-registers. This caused some nasty consequences,
there might be only two bytes on a peripheral card, first you write a
register number select to select the actual register and then use the
other byte for the actual data transfer to the recently selected
register.

The IN instruction might read from one register, but OUT to the same
address would cause writing a completely different register, i.e. no
register readbacks.

Some exotic cards might have some nasty side effects of the IN
instruction (e.g. advancing the register select) and you could not
safely use some diagnostics tools to peeking such registers.

[upsid...@downunder.com]

On Fri, 26 Apr 2013 11:04:05 -0700, John Larkin
<jla...@highlandtechnology.com> wrote:


>The 11 had no i/o instructions, which was cool. Devices were memory
>mapped, so no opcodes were wasted on klunky IN and OUT instructions,
>and any memory opcode could operate on i/o, too. 68K worked like that,
>too. The 68K was just a better PDP-11.
>
>The PDP-11 was programmed in octal, and with a little practice you
>could assemble instruction in your head and map them directly into
>octal. I can still do some.
>
>MOVB (r1)+, R5 is (I think) 112105 octal.

The dual operator instruction format was 1+3+(3+3)+(3+3) bits and most
single operation instructions 1+9+(3+3) bits, thus it was quite easy
to write small test programs directly with the binary front page
switches. Of course, calculating the relative branch offsets in your
head was a challenge :-).

It is interesting to note that the Intel 8080 had the MOV instruction
in the 2+3+3 bit format and most other instructions in the 5+3 bit
format. In some early documents, Intel used octal, which worked fine
for this instruction mapping. Unfortunately, Intel then switched to
hexadecimal notation and it became quite hard to program it in machine
language.

[Michael A. Terrell]

John Larkin wrote:
>
> Michael A. Terrell wrote:
> >

> > Ask Intel.
>
> The last time I tried to ask Intel anything [1], they insisted that I
> be certified first. That involved furnishing all sorts of company info
> and presenting a plan that proved we would build at least 10K systems
> the first year. All that to get a datasheet!

Yet you asked me what they newest chips support.

Based on the number of boards in use, VME/VXI is obsolete.

[josephkk]

Ah. Now i get it. That is why HP wanted Compaq.

?-)

[josephkk]

On Mon, 22 Apr 2013 07:49:11 -0400, "Michael A. Terrell"
<mike.t...@earthlink.net> wrote:

>
>John Larkin wrote:
>>
>> DEC wrote operating systems (TOPS10, VMS, RSTS) that ran for months between
>> power failures, time-sharing multiple, sometimes hostile, users. We are now in
>> the dark ages of computing, overwhelmed by bloat and slop and complexity. No
>> wonder people are buying tablets. DEC understood things that Intel and Microsoft
>> never really got, like: don't execute data.
>
>
> I've had Win2K run over nine months, between power failures that
>lasted longer than the UPS batteries. DEC had more control over the
>computers, and a tiny fraction of the number running Windows or Linux.
>
>
> If DEC was so damned good, why were they unable to survive? Their
>IBM 'clone' (Rainbow 100) was very overpriced, not compatible, and did a
>very quick death spiral. Admit it. It was a dinosaur company with a
>very tiny customer base.

Same old management problem. Even though the Alpha ran rings around Vaxes
and PDP10s, and those were the current cash cows. They crippled Alphas to
keep their old "core" business. That decision destroyed them. See also
the Rainbow.
IBM has barely survived similar mistakes with the PC. Also where is Data
General (who had the Nova mini and the Micronova chip), Sequent, Sierra,
Nixdorf, Pyramid, Non-stop computing, and many other minicomputer (and
transaction server) vendors of the time. All gone or morphed into
something else. Sun was the last one standing and they focused on
engineering workstations. SGI Iris workstations are gone as well. Mentor
and Daisy have morphed into software companies.

?-)

[josephkk]

On Tue, 23 Apr 2013 06:59:05 -0700, John Larkin
<jjla...@highNOTlandTHIStechnologyPART.com> wrote:

>
>DECs RT11 OS was cloned to become CPM and Microsoft DOS, and lives on in the
>Windows command line.

Absolute idiotic poppycock. Neither CPM nor Portland Software's 8086 DOS
had anything but some incidental common commands to RT11. They were
utterly different creatures written from scratch.

>
>What sort of computing system did you have in 1969? I had a PDP8 running Focal.

>What did you compute on in 1975? I had a PDP11 timeshare system with around 20
>users.
>
In 1975 i had a AN/UYK-7 which was about equivalent to a small VAX of the
time. It was designed as a dedicated real time military sensor and
weapons control platform (NTDS), the precursor of C3I. It did about 1
32-bit VAX MIPS.

?-)

[Jasen Betts]

On 2013-04-27, josephkk <joseph_...@sbcglobal.net> wrote:
> On Tue, 23 Apr 2013 06:59:05 -0700, John Larkin
><jjla...@highNOTlandTHIStechnologyPART.com> wrote:
>
>>
>>DECs RT11 OS was cloned to become CPM and Microsoft DOS, and lives on in the
>>Windows command line.
>
> Absolute idiotic poppycock. Neither CPM nor Portland Software's 8086 DOS
> had anything but some incidental common commands to RT11. They were
> utterly different creatures written from scratch.

Over half the OS calls are identical,

[DecadentLinuxUserNumeroUno]

On 27 Apr 2013 10:52:42 GMT, Jasen Betts <ja...@xnet.co.nz> wrote:

>On 2013-04-27, josephkk <joseph_...@sbcglobal.net> wrote:
>> On Tue, 23 Apr 2013 06:59:05 -0700, John Larkin
>><jjla...@highNOTlandTHIStechnologyPART.com> wrote:
>>
>>>
>>>DECs RT11 OS was cloned to become CPM and Microsoft DOS, and lives on in the
>>>Windows command line.
>>
>> Absolute idiotic poppycock. Neither CPM nor Portland Software's 8086 DOS
>> had anything but some incidental common commands to RT11. They were
>> utterly different creatures written from scratch.
>
>Over half the OS calls are identical,

I think Bill Gates' early endeavors involved DR. Did j'all just miss
that one?

[Jasen Betts]

On 2013-04-27, Jasen Betts <ja...@xnet.co.nz> wrote:
> On 2013-04-27, josephkk <joseph_...@sbcglobal.net> wrote:
>> On Tue, 23 Apr 2013 06:59:05 -0700, John Larkin
>><jjla...@highNOTlandTHIStechnologyPART.com> wrote:
>>
>>>
>>>DECs RT11 OS was cloned to become CPM and Microsoft DOS, and lives on in the
>>>Windows command line.
>>
>> Absolute idiotic poppycock. Neither CPM nor Portland Software's 8086 DOS
>> had anything but some incidental common commands to RT11. They were
>> utterly different creatures written from scratch.
>
> Over half the OS calls are identical,
>

Replying to myself, that doesn't make DOS any closer to CP/M than linux
is to unix.