Elsewhere tor let us know about the NORD-10:


Sam quoted comment is this one from the same thread (followups here, please, or in another new thread, as they are OT there) and reminds me of the Z80 which has an alternate register set.

I'm also reminded of ARM, which originally had 4 partially overlapping register banks for the 4 modes of operation. The FIQ (fast IRQ) mode overlays a total of 7 registers.

I've also brought this into a new thread because I'm reminded of this press clipping where Chuck Peddle is quoted as saying the 6502 team "tried an 8-state machine which would dump the accumulator as well as the program counter and status but since it added another 10 mils to the chip, we discarded it."

We know that the 6502 had an aggressive chip die size target (to make the aggressive price target sustainable) and we know that the die size was exceeded at some point during the chip layout, with surgery needed. Some untidyness remains which we (in the visual6502 team) believe to be remnants of that shrink. What we don't know for sure is what functional changes were needed to support the shrink. That quote might indicate that the interrupt handling originally pushed/restored A (like 6800), and the reason it doesn't is because of the need to reduce the size of the chip.

Cheers
Ed

Maybe they took it out when Motorola sued MOS because the 6501 was pin compatible with the Motorola 6800 and they took it out when they made the 6502 which isn't pin compatible? I don't know because I'm only guessing...






http://www.commodore.ca/history/company ... nology.htm

It's an idea, but no: the die shrink was pre-production and the suit was afterwards (Nov 3rd, 1975)

The 6501 and 6502 chips were prepared concurrently: most likely only the contact masks differ (all other masks the same) - the schematics are labelled as 650X and cover both chips.

I think it's speculation as to whether MOS ever expected to get away with mass sales of the 6501, but they certainly succeeded in settling that suit and having the other product already on the market. The advert from August 75 is for 6501 but the one for September mentions both parts.


This quote presumably from here. But surely the wescon75 show was in September?

Cheers
Ed

Context is required to understand this thread. To bring everyone up to speed with the "executive summary" version, this is what happened to spawn this thread.

Garth had said that the existence of a pipeline made interrupt response time slow, implying it was unacceptably slow. I disagreed -- you'd need a pipeline in excess of 7 stages to begin to slow the processor response to an interrupt if the CPU had internal registers allowing it to switch contexts instantly. Further, maintaining a complete alternate state would allow the CPU to change contexts faster than current 6502 speeds, because after the CPU spends its 6 cycles fetching the interrupt vector, you still need to save and restore A, X, and Y.

Garth later (correctly) indicated that it's not re-entrant, to which I responded that re-entrancy isn't required if you structure your ISR as a coroutine instead of a subroutine.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Thank you for proving just about every one of my points above. But...



Here, you're distracting from my point. The point is to not touch outside memory to save state. The CPU maintains internal registers. Register selection would work like this (in untested Verilog):



where handlingIRQ is true if the processor has received an interrupt. Note how as soon as this signal is asserted, the selection of internal register changes immediately. It's not all that much harder to extend this to handle the case of pipelining either.

The 'addressingProblem' signal exists because, sometimes (e.g., as when using BRK to implement debugger breakpoints) you want to read the "problem-state" CPU registers. I didn't state how exactly this is to be done, only that it is to be made possible. It is valid if, and only if, handlingIRQ is true. If false, it's completely ignored, and all accesses occur to the problem-state register only.




I_PC is the interrupt handler's program counter, yes. R_PC is the "return to" program counter which RTI would stuff into PC when it's done.



Your system assumes RAM and the ability to redefine code on the fly. I assume ROM, and the handler tree is static. In either case, it's an implementation detail intended to not to recommend how to structure the IRQ handler except insofar as to demonstrate how an interrupt co-routine would look like as compared to a typical sub-routine.

Note that your approach, as described, still treats the interrupt handler as a subroutine.



No it doesn't. It's exactly what interrupts are for -- notification of some external stimulus to a main program.

For example, your approach to handling interrupts, where you do all interrupt processing right in the ISR would emphatically crash nearly every multitasking kernel I can think of. This is because kernels depend on IRQ handlers running very, very, very, very fast. Most peripherals, being I/O bound, are horrifically slow compared to the speed at which the kernel would expect to change tasks. Doing all I/O processing in the interrupt handler that generated the need for it would starve programs of their required processing time. You'd never get anything done!

You complain about polling, but yet you celebrate cooperative multitasking. These are identical in performance, and as Windows 3.0 and its predecessors have shown, disastrous in all but the most specialized cases. What you want is preemptive multitasking. Instead of the CPU hardware itself saving and restoring program state, which you depend on in your model, the kernel decides which context to enact next. This process is called scheduling. This is most easily achieved by simply switching kernel stacks before executing RTI and its required register reloads.

Remember, the Commodore-Amiga was an 7.15909MHz 68000 (less than 2 MIPS on average!) with gargantuan interrupt latencies compared to the 6502. Yet, its preemptively multitasking kernel was necessary and sufficient for it to find applications ranging as menial as a games machine that raced the electron beam on a CRT all the way up to helping to monitor nuclear reactor stations, powering NASA data acquisition systems, and more. Note that the 68000 has to save and restore, manually, a heck of a lot more state than the 6502 or 65816, and must do so manually, to a large extent. Clearly, handling most interrupts in user-space was not a problem for this machine.

What you're doing is using interrupts as a means to support a kind of hardware-implemented multitasking, which is fine for only the simplest of requirements. But, it will fail utterly in the general case.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

That is correct, yes, particularly true on multi-processor systems.



Why?



But, look at what you're doing. Your ISRs don't do a whole heck of a lot of work. In fact, you contradict yourself earlier when you said that you didn't just set a flag, and a few paragraphs later, you wrote that one of your ISRs did exactly that, and no more.

Look at the typical device driver in an OS like, say, MS-DOS. A device driver basically consists of a library containing two entry-points: interrupt, and schedule. These routines are intended to be used by two different halves of the running system. Your application calls schedule to schedule an I/O request of some kind (for now, let's ignore error handling, and assume all I/O requests are perfect and valid). The device driver looks at the request, and queues it up. In the case of a VIA-based shift register, it might be described by a data structure like this:



So, schedule would keep a list of these requests. Once it's been added to the list, it's job is done. (If no pending I/O operation exists, it might send the first byte itself just to kick off the event loop.)

Now, when the VIA issues its next interrupt, the OS interrupt handling chain figures out that it needs to invoke this device driver's "interrupt" entry point. The interrupt routine, then, knows it needs to grab the next byte from its current buffer (or pick a new buffer from the list if it's done), and write it to the VIA. Note how simple this task is:



There are ways of optimizing this, such as interning the I/O request record directly into zero page (the 8-bit Atari OS does this, for example), but it serves for illustrative purposes.

What we see, despite DOS not being a multitasking operating system, is the use of interrupts to give the illusion of multiple concurrently running processes. In this case, it makes the attached peripheral look very much like a cooperating, self-running service. This is actually what interrupts were invented for, for back in the days of mainframes, keeping all of your I/O devices as busy as possible while the CPU churned out reports was compulsory. Remember companies were paying IBM and Univac millions of dollars yearly for the privilege of having a mainframe in their data center!

Now, let's look at an operating system like OS/2 2.0, which uses the same basic I/O driver architecture, but now includes the ability to switch amongst any number of ready-to-run programs at any given moment. The operating system cannot switch programs while it's executing code in the kernel, because doing so represents a consistency problem. Knowing that switching user-mode contexts takes some amount of time means that you need a faster CPU to keep up with the same real-time constraints you had back in plain old DOS. However, it's not that much, especially when you consider that most context switches occur only at I/O request completion times or, if no I/O is in progress, between 10 to 100 times per second. For a CPU running, say, 12MHz, that is basically nothing for all but the most critical real-time constraints.

The structure of our ISR now looks something like this:



As you can see, not a whole lot has changed. The only real difference is that, in recognition of real multitasking, you now notify a user-level process upon completion of an I/O request, and you now have to be aware of dynamically managed memory.

But, notice, in neither case do I spend a whole heck of a lot of time doing any one thing. I have no tight loops, I have no dependencies on outside modules, and I certainly don't waste time doing block memory moves or the like. Those things are all to be done by user-level processes, precisely because they are interruptable.



Nope -- at worst, they're the same, but at best, they're as fast as a cache hit. It depends on the cache settings for I/O space, the speed of the bus used to talk to the peripheral, and whether the peripheral itself generates any wait-states or not.



You can, if you don't particularly care about performance. (In fact, I'm using this exact technique with the Kestrel-2 right now, because the J1 lacks interrupt capability of any kind.) The reason you have interrupts is to give the OS a chance to change CPU state, on demand. If I'm running a low-priority program on my computer which takes 30 seconds to complete a task, and I get a network packet, I do not want my computer to wait 30 seconds before handling that packet. The interrupt causes the OS to switch run-time state from the low-priority task to the device handler task. This is what makes preemptive multitasking preemptive, and is precisely why cooperative multitasking does not work in the general-purpose case.

Perhaps a better example is typing on a heavily-loaded web server. It takes a computer up to one millisecond to process a network packet from the Internet into an application's user-space, as measured by real-world, customer-facing services here at work. Can you imagine receiving hundreds of packets while the computer is at the same time trying to handle a keyboard, entirely in kernel-space? Typing speed slows noticeably, to a point where you just want to throw a brick at the computer's monitor. (Actually, I've experienced exactly this back in my CariNet days, albeit with Linux instead of something like WIndows 3.1, and instead of network packets, it'd be handling disk I/O requests on non-DMA IDE drives. Since the drives have to be spoon-fed by the CPU in kernel space (where interrupts are non-reentrant for kernel consistency reasons, as explained above), keyboard interactivity would drop to near-useless levels. Had the disk drivers sat mostly in user-space, Linux would have kept up with the keyboard without breaking a sweat. Oh, how I miss the 90s.)



Right.



No, you can have as few as two running en toto, and you'll still run into jitter and latency caused by the cooperative nature of the system.



That's great, but you're not the only engineer using 65xx products or developing 65xx software. Because of this, we now need to consider the general case.

This whole argument started because you expressed concern that pipelines introduces lengthy delays in handling interrupts. I countered with my stating that's not necessarily the case if you switch contexts in the following cycle. Yes, this means you lose the ability to be re-entrant, but I've found 100% of all ISR cases are themselves not re-entrant (or, can be refactored so as to not require it), unless you have long-running ISRs. By long running, of course, I mean that you have an ISR that runs as long as any user-level process would be expected to run. If you're the sole user of the machine, having been the sole author of the software running on said machine, running with hardware designed and implemented entirely by yourself, this might be acceptable. But, for the general purpose, that's a tall order to fulfill, and will breakdown almost immediately.



And this is what I'm talking about when I refer to short-lived interrupt handlers. This is wonderful, and indeed exemplary.



Non sequitor -- I never made this claim.



No, this is not what I'm saying. What I was saying was that cooperative task switching is far from real-time. Here's a great program to run that amply proves my point. Run this on Windows 3.1 some day, and tell me how it works out for you:



This is an infinite loop, and because it doesn't voluntarily give control back to Windows (by calling GetMsg()), it will kill your entire system dead, except for ISRs of course. You'll be able to move the mouse, but that's about it. Most if not all disk activity will cease. Network activity will stop cold. Animations playing on the screen will die. The only means of recovery is to kill the program through some means, or to just straight-up reboot.

Now, I know that most Forth implementations are aware of such deliberately malicious code, which is why most implementations of WHILE, UNTIL, AGAIN, and REPEAT embed a call to PAUSE as part of their definitions. But, even here, we can circumvent it. Try this on your next multitasking-capable Forth:



Ahh, but who in their right mind would deliberately write software to bring a machine to its knees like this? Well, a few people come to mind -- QA engineers (which I am), load-test engineers, and brats who think they're 1337 script-kiddies. But, on the whole the biggest source of sluggishness in a program won't come from deliberate attempts to bring a system down; rather, it'll come from busy engineers whose code sits at the "works for me" level of quality, and isn't adequately tested to cover all control flows. When you get that, invariably, you end up with accidents that result in infinite loops, or people using algorithms with time-complexities that are O(n^2) instead of O(n log n), etc. So even if you do PAUSE judiciously in your sources, the dynamic behavior of a program can (and I'm not saying yours does, but again, in the general case) result in really lack-luster performance on cooperatively multitasking systems.

This is where interrupts and preemption come into play, and why they work so well together. Knowing that it's possible to wire the NMI handler to an OS routine that restores control over the machine, why not generalize this to allowing the computer to forcefully switch to another program? That's all preemptive multitasking is, and it actually isn't hard to do. In fact, you have to write a cooperatively-multitasking kernel first, and then make it preemptive by calling PAUSE (or whatever your system call equivalent is) in the ISR of the timer handler.

You can get very good performance if your kernel is built to handle real-time constraints (consider QNX or L4 microkernels, for example; and, you can snow even these if you elect to forego the use of MMU for memory protection), even if your code sits in user-space.



While I periodically muse about it, the availability of FPGA hardware renders the 65xx architecture obsolete for my needs. The J1 processor, despite its 16K code-space, 64K data-space limitations, so completely out-classes the 65816 in performance that it's hard for me to consider going back. I do need to give it the ability to see more than 64K of memory some day, though. Oh, and I do need to add in interrupts too.

That being said, the Kestrel-2's I/O registers and memory interfaces should be relatively simple to adapt to the 65xx architecture, since the Wishbone bus is so close to the 65xx's. So, if I ever do manage to get into the 65xx mood again some day, it's a fairly simple matter of replacing the CPU binding and writing a new software tool-chain for it. Everything else should "just work."

My Linux desktop PC is running 250 tasks right now, of which about half are kernel tasks, and the rest user tasks. Some tasks run 4 times, one on each (virtual) core. Total CPU time taken by all these tasks is less than 1% on average, so it's not a big deal.

On the other hand, if you have re-entrant interrupts, with different priorities, long running ISRs are not a problem.

I'm doing that right now for my latest project. I have some hardware device that produces some data every millisecond, and that data is only valid for 100 microseconds. Processing the data takes about 40 microseconds. My solution was to put the processing in an ISR. This is simpler, and more efficient than using a task. As a consequence, I also use fewer tasks (saving stack memory), and they all have fairly low priority. This allows me to use a non-preemptive scheduler, which is also simpler, because it avoids all the critical sections you'd need with a preemptive scheduler.

Note that I write real-time embedded software, not general purpose PC software, so your mileage may vary.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I've also done quite a few projects like that too, where there's just a big main loop polling all kinds of events. Anything that needs to be done faster is handled by an ISR. Many kinds of problems can be handled quite well that way.

Well, my Linux desktop runs some 765 processes right now, with load average: 0.00, 0.03, 0.05

As to a multitasking system crashing if an interrupt handler takes longer than context switch time.. no, it doesn't, but of course if the interrupt handler doesn't return then the system will never get back to user level. Higher-priority interrupts may still be handled, so that it's possible to 'ping' the network interface and get a response, for example. But generally a too slow interrupt handler will simply slow down the system and give other problems. Not crashing, though (as in 'kernel panic' and boom).

-Tor