What if independent MOS Technology had survived?

[whartung]

litwr wrote:

This idea of fully relocatable code is a chimeric descendant of PDP/VAX-11 ISA. But even PDP/VAX-11 couldn't get it. Nobody needs this. It is impossible to use program without a proper loader in the complex OS. IMHO PER is just a waste of the codespace. Did anybody use it?

Quote:

EDIT. It is also worth to note that there is a true OS for 6809/6309 - FLEX. 6502 family missed this. 6502 has only Basics and Forth.

FLEX was no more exciting than CP/M in the OS space -- i.e. it was a shell that could load programs and offered a BIOS/BDOS. SpartaDOS was no slouch on the Atari 8-Bit.

OS/9 was a multi-tasking OS for the '09, and, early on, all of its processes were written using position independent code, no launch time loader was necessary.

Early MacOS did this also, relying on PIC routines. This was fully exploited by the MultiFinder. There was system support (notably for calling different segments of code within the application), but no real loader per se. Of course, UCSD P-Machine did this also, at the p-code level. All of their code was PIC with the segments tied dynamically loaded at runtime. Both the Mac and UCSD required compiler support for multi-segment calls.

You could do the same thing on the '816 (IIGS did this a little bit, with desk accessories), with the caveat that your individual processes could only have < 64K of code, but they could access more than that for data. The OS would need to have a way to portion out Bank 0 as a shared stack space among the processes, but (almost) 64K of Bank 0 should handle hundreds of processes. Each processes meta data can specify a stack size.

None of this requires a loader, but it does need a decent memory manager. And, yes, there's no protection among the processes -- that's a different issue.

[Dr Jefyll]

BigDumbDinosaur wrote:

Quote:

Why are you so sure that 6809 or 6309 has bigger power consumption and interrupt latency?

Data sheets, my friend, data sheets. Also, it is a well-known fact that the 6502's interrupt latency is one of the lowest of any microprocessor design.

So, which 6809 and 6309 datasheets are you using, BDD? My 1981 Motorola manual says the 6809 Fast Interrupt Request (FIRQ) takes just 9 cycles after completion of the currently-executing instruction. IIRC this is just one cycle slower than an '816 in Native Mode. IOW, 9~ vs 8~. These are both favorable figures. (As for 6309, I suspect its FIRQ response may take as little as 7~ due to freedom from dead cycles when not in Emulation Mode but I haven't checked this.)

Re power: the 6309 is, like the 65816, a CMOS design. Have you actually compared their respective consumptions?

Edit: "after completion of the currently-executing instruction" is somewhat of a wild card. Multiply, for example, is a comparatively slow instruction, and its use will impact interrupt latency. But it would be misguided to praise 65xx for its lack of a multiply instruction! And of course if its avoidance really is desirable then the 68/6309 coder can simply not use it.

[GARTHWILSON]

Dr Jefyll wrote:

Edit: "after completion of the currently-executing instruction" is somewhat of a wild card. Multiply, for example, is a comparatively slow instruction, and its use will impact interrupt latency. But it would be misguided to praise 65xx for its lack of a multiply instruction! And of course if its avoidance really is desirable then the 68/6309 coder can simply not use it.

Perhaps it could have been made to be interruptible like the 816's memory-move instructions are (although that might make the interruptible instruction take longer overall).

[BigEd]

Some ARMs have a selectable mode, as to whether an interrupted instruction should be completed, or abandoned (and rerun when the ISR returns.)

FWIW there's a book all about the 6309, legitimately available as a free PDF:
http://cyberabi.ipower.com/Downloads/The_6309_Book.pdf
(It suggests a FIRQ takes 10 cycles, and weakly implies it's the same in both native and emulation mode.)
(And there's a 6809/6309 ref card here.)

[Arlet]

GARTHWILSON wrote:

Quote:

But that's comparing apples to oranges. How long does the '816 take to do the same divide ?

What I'm saying is that a divide instruction is not always as valuable as the tables which the 6809 and 6309 do not have the memory range to address.

Not always, but a division is much more common than a log. And when I do need a log, it's another big assumption that 16 bits will be sufficient.

Quote:

The fastest ASIC 816's run over 100MHz which is about 30 times as high a clock rate as the fastest 6309'

What ? We were talking about cycles, not microseconds. And even if you're going to introduce clock rate, it would be honest to pick off-the-shelf parts for both contenders, and not pull out hypothetical ASICs that none of us have access to.

[Arlet]

The 6309 has two interrupt levels, which can help to make it faster than a 6502. If you have multiple interrupt sources, but only one that's time critical, you can attach that to the FIRQ, and save time because you don't have to look up the interrupt source.

[Aslak3]

Arlet wrote:

The 6309 has two interrupt levels, which can help to make it faster than a 6502. If you have multiple interrupt sources, but only one that's time critical, you can attach that to the FIRQ, and save time because you don't have to look up the interrupt source.

Of course the 6809 has the same FIRQ/IRQ (and NMI) setup.

What attracted me to the 6809 for my projects is the programming model. I'm still waiting to see a dynamic memory allocator written for the 6502, just to see how it "reads".

That said it's good to see some numbers on the whole "6502 interrupt performance" thing.

[Arlet]

Quote:

I'm still waiting to see a dynamic memory allocator written in the 6502.

I have part of it done, but it's painful Compared to 6502, the ARM version was a breeze. I'm also hoping someone will make a 65816 version.

[GARTHWILSON]

Arlet wrote:

Not always, but a division is much more common than a log. And when I do need a log, it's another big assumption that 16 bits will be sufficient.

I have tables at the link for many other things too:

• squares (with 32-bit output, helpful in speeding multiplication)
• inversion (with 32-bit output, helpful in division, since you can multiply by the inverse)
• sin (also good for cos & tan)
• asin (also good for acos)
• atan
• logs in three ranges (including suitable for logs of numbers very close to 1)
• antilogs in three ranges (including suitable for antilogs of numbers very close to 0)
• three different square-root tables
• bit reversal (for ordering the outputs of the butterflies of the fast Fourier transform)
• a multiplication table up to 255x255.

Quote:

Quote:

The fastest ASIC 816's run over 100MHz which is about 30 times as high a clock rate as the fastest 6309'

What ? We were talking about cycles, not microseconds.

We're talking about speed (in microseconds), and clock rate is directly related.

Quote:

And even if you're going to introduce clock rate, it would be honest to pick off-the-shelf parts for both contenders, and not pull out hypothetical ASICs that none of us have access to.

Ok, the off-the-shelf ones available to hobbyists run at clock rates at least four times that of the 6309. But we've talked here about the modern successes of the 65's which, is sales volumes, have come in ASICs. Have there been any such 6309 ASICs with stepped up clocks? (Maybe there are and I just haven't heard of them.)

Quote:

The 6309 has two interrupt levels, which can help to make it faster than a 6502. If you have multiple interrupt sources, but only one that's time critical, you can attach that to the FIRQ, and save time because you don't have to look up the interrupt source.

Even if the '02 has to poll an additional source for lack of a third interrupt input, it's still much faster than the 6309, due to its much higher clock rate. The 6309 is not helped by the fact that its FIRQ takes 10 clocks compared to the 7 of the '02.

With the '02, I put my RTC on NMI\; not because it needs to be particularly fast (although it gets that treatment), but just that it's running most of the time and putting it on NMI eliminates all polling from the NMI ISR (which also doesn't push X or Y, since it doesn't use them) and eliminates that part of the polling from the IRQ ISR.

[BigEd]

(I'd feel more comfortable if we could get back to "this thing is a good thing" and away from "this thing is better than that thing")

[litwr]

whartung wrote:

FLEX was no more exciting than CP/M in the OS space -- i.e. it was a shell that could load programs and offered a BIOS/BDOS. SpartaDOS was no slouch on the Atari 8-Bit.

OS/9 was a multi-tasking OS for the '09, and, early on, all of its processes were written using position independent code, no launch time loader was necessary.

Early MacOS did this also, relying on PIC routines. This was fully exploited by the MultiFinder. There was system support (notably for calling different segments of code within the application), but no real loader per se. Of course, UCSD P-Machine did this also, at the p-code level. All of their code was PIC with the segments tied dynamically loaded at runtime. Both the Mac and UCSD required compiler support for multi-segment calls.

You could do the same thing on the '816 (IIGS did this a little bit, with desk accessories), with the caveat that your individual processes could only have < 64K of code, but they could access more than that for data. The OS would need to have a way to portion out Bank 0 as a shared stack space among the processes, but (almost) 64K of Bank 0 should handle hundreds of processes. Each processes meta data can specify a stack size.

None of this requires a loader, but it does need a decent memory manager. And, yes, there's no protection among the processes -- that's a different issue.

But CP/M is very exciting in OS space. It has dozens thousand useful software items. It can run with almost any 8080/8085/z80/v20 hardware. CP/M was useful to the late 90s. There is good software for 6502 too, but it is strictly isolated in Apple ][ zone, or Atari 800, or Commodore 64, .... The absence of common OS always made 6502 position very feeble. I'm still curious why there were no attempts to port cp/m for 6502 in 70s. IMHO it was easy just to change start of TPA from $100 to $200. It is also easy to convert 8080/z80 codes to 6502.
BTW CP/M-programs and even COM-programs for much more advanced MS-DOS do not require a loader but it is a sign only of a simplicity of these OS. Even PDP-11 OS, which use hardware with a very good support for the code relocation and are relatively simple, use loaders.
EDIT. IMHO Independent MOS Technology would provide the environment where common 6502+ OS soon would become a necessity and would be eventually made.

[BigEd]

I feel we almost need a separate thread for questions of OS advantages and history. I suppose we've got into an enthusiastic debate about the 70s/80s/90s generally, and the winners and losers as things happened. Of course, things could have happened differently. Success in the embedded world - both 68xx and 65xx having had success there - is less visible than success in the world of computers.

I've just finished reading an oral history of some of the engineers and managers behind National Semiconductor's 32000 CPU series. It's interesting to read about the challenges and the mistakes. One takeaway from them is that it was all about the software, and about the commitment of a company to a product line and its future support. If NatSemi were not as credibly committed as Motorola who were not as credibly committed as Intel, then Intel wins the corporate buyin from huge important customers. If Dell picks the '386 because of the available software for the end-user, it's not a statement about how excellent the alternative choices were.

On the topic of "What if independent MOS Technology had survived?" I'm sure that the availability of software and the commitment to support, manufacture and development would have been crucial. Visicalc changed Apple's fortunes, and that helped the 6502 and WDC to keep going. But WDC never had the size to change the world. If MOS had survived independent of Commodore, they would have needed to grow like Intel and fight like Intel in order to change the world. They would have needed to embrace something like Unix, I think, and that would mean adding layers to the architecture the way Intel did. Intel themselves had several tries at a fresh start, away from x86, and got nowhere.

[Arlet]

Quote:

One takeaway from them is that it was all about the software, and about the commitment of a company to a product line and its future support.

I think Intel was in a very starting good position because of their early design choices, allowing for a long and smooth upgrade path with regular performance increases, while keeping support for the existing software base. Try that with the 6502, like we've talked about in this thread, and you get stuck dealing with the bad baggage from the beginning.

[BigEd]

AIUI, one disadvantage Intel had, internally, was the huge success of their RAM business. It took a determined effort, first, to sponsor a CPU project, and second (much later) to drop the RAM and become a CPU company.

I'm not sure that the 6502 couldn't have pulled similar tricks to the x86, but I think it would have needed prefix bytes, or postfix bytes, or both. Once you have some on-chip instruction buffer or cache, and a wider path to memory, that starts to look less problematic. But eventually, as we saw with x86, you end up with very complex and power-hungry implementations to raise the performance.

[Arlet]

I think the 6502 even with prefix/postfix bytes would still suffer from a barely useful zeropage and the sizeable chunk of opcodes involved with it. Reusing that opcode space would break compatibility. Later generations of '02 have also quickly claimed large parts of opcode space for dubious extensions, such as the bit test/set/clear instructions. It would have been better to go for multi-byte opcodes from the beginning.

Quote:

But eventually, as we saw with x86, you end up with very complex and power-hungry implementations to raise the performance.

Sure, but I don't think that's a specific x86 issue. Try getting the same performance out of an out ISA, and you'd also end up with the same complexity.