6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 10, 2024 7:38 am

All times are UTC




Post new topic Reply to topic  [ 217 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8, 9, 10 ... 15  Next
Author Message
 Post subject: Re: 65VM02
PostPosted: Sun May 21, 2017 7:01 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
Hugh Aguilar wrote:
I will give some thought to the subject of ISRs being interrupted. This might be possible. I'm concerned that this might be dangerous, and make the system prone to bugs, but maybe it is okay.

Nested interrupts are common on many systems and when correctly implemented, can substantially improve throughput, especially if the concept of interrupt priority is in the picture. The interrupt service routine has to be written so it is transparent and fully reentrant, which generally means only the hardware stack is used to maintain state as the ISR executes. Reliance on special MPU flags may sabotage reentrancy, since the flag(s) is(are) technically not usable by more than one ISR, unlike stack space.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Last edited by BigDumbDinosaur on Mon May 22, 2017 4:02 am, edited 1 time in total.

Top
 Profile  
Reply with quote  
 Post subject: Re: 65VM02
PostPosted: Sun May 21, 2017 7:07 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
BigDumbDinosaur wrote:
The interrupt service routine has to be written so it is transparent and fully reentrant, which generally means only the hardware stack is used for for maintain state as the ISR executes.

Yes, some processors use dedicated register banks for interrupts, such as older ARM CPUs. Sounds like a very nifty idea, until you want to make your interrupt reentrant, and then you have to grab all those registers and save them back on the stack.


Top
 Profile  
Reply with quote  
 Post subject: Re: 65VM02
PostPosted: Sun May 21, 2017 7:21 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10975
Location: England
Isn't it a tactic somewhat like a link register, which saves you work in the innermost level and is otherwise cost-neutral?


Top
 Profile  
Reply with quote  
 Post subject: Re: 65VM02
PostPosted: Sun May 21, 2017 7:35 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
Saving the ARM registers costs a bit extra because you have to save the IRQ link register, and then switch to SVC mode, and save that link register as well.


Top
 Profile  
Reply with quote  
 Post subject: Re: 65VM02
PostPosted: Sun May 21, 2017 11:47 pm 
Offline

Joined: Fri Jun 03, 2016 3:42 am
Posts: 158
Arlet wrote:
Quote:
ISRs getting interrupted(?)! Something to think about! 

It's pretty standard on ARM Cortex, typically with 16 or more priorities. Once you get used to it, it works great because you can spend a long time in a low-priority interrupt, without having to worry about blocking higher priority ones.

That could be useful when there is no multi-tasking OS and so your ISRs are effectively tasks.

With the 65VM02 however, I'm expecting to have a multi-tasking OS. If you need to spend a long time doing something, that code would be a task rather than an ISR.

Note that it is possible for a task to be closely associated with an ISR. When an ISR executes, it can move a particular task to the front of the list, and it can force a task-switch so that after the ISR concludes this task will execute right away (this task has presumably been in READ-BUFFER waiting for the ISR to put some data in the buffer, because it had found the buffer empty when it called READ-BUFFER, so it had to wait) --- effectively, the task is a direct continuation of the ISR --- the task though, follows the rules of all tasks, in so much as it can get a task-switch done to it before it completes whatever it is doing.

This would actually be used for a high-priority interrupt though, not a low-priority interrupt. The example I gave was that you have some input that dumps data into the micro-controller in bursts. The ISR fills up a buffer with this data, but when it sees that the buffer is over half full, it forces the task waiting in READ-BUFFER to execute so it can get the buffer emptied out before the buffer overflows.

I don't really get what you mean about a low-priority ISR taking a long time.


Top
 Profile  
Reply with quote  
 Post subject: Re: 65VM02
PostPosted: Mon May 22, 2017 2:01 am 
Offline

Joined: Fri Jun 03, 2016 3:42 am
Posts: 158
Arlet wrote:
BigDumbDinosaur wrote:
The interrupt service routine has to be written so it is transparent and fully reentrant, which generally means only the hardware stack is used for for maintain state as the ISR executes.

Yes, some processors use dedicated register banks for interrupts, such as older ARM CPUs. Sounds like a very nifty idea, until you want to make your interrupt reentrant, and then you have to grab all those registers and save them back on the stack.

This is one reason to not allow ISRs to be interrupted --- the 65VM02 could have shadow registers that are used by the ISR rather than saving and restoring registers to the return-stack --- this should speed up ISRs significantly, although it might be expensive in terms of chip resources.

Currently, the AIRQ interrupts automatically save A D P and PC to the return-stack (the return-stack in page-one, not the return-stack indicated by D prior to the interrupt, as D gets set to 0 for the ISR). I would be okay with having A D P and PC swapped out with shadow registers instead. I don't think that X Y S and IP should be swapped out with shadow registers however, because not every ISR needs to use X Y S and IP (IP is only used if the ISR is written in Forth, which is likely pretty rare).

BTW: I just realized that I have a bug in my current design. :oops: I had said that A P and PC are automatically pushed to the return-stack in page-one, but I'm not taking into account that S is for the current task (which has its own return-stack) rather than for the ISR's return-stack. I'll have to fix this in the next update on the document. 8)


Top
 Profile  
Reply with quote  
 Post subject: Re: 65VM02
PostPosted: Mon May 22, 2017 2:40 am 
Online
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8538
Location: Southern California
Quote:
I don't really get what you mean about a low-priority ISR taking a long time.

You partially covered it by having it trigger a task-switch.

Imagine a flash memory where you're storing data, and it has two 1K buffers, like one I've used had. You transfer data to buffer 1, then tell it to start the process of writing that buffer to flash, and you fill buffer 2 and exit the ISR or task and wait for the device to tell you it's done with the first write (which may take up to 20ms). For maximum throughput, you can use its "ready" output to interrupt. When it does, you tell it to start writing buffer 2's contents to the flash, and you write new data to buffer 1...and so on, until you're done.

A printer might be another one with low priority when it says it's ready for more data, but it could take a long time to feed a lot of data. These would be ok to pass off to a task; but even in that process, there could be other interrupts that can't even wait for the task-switching process to complete before they must get attention.

The '02 was not originally designed for desktop home computers (although it sure got into a lot of them because of its low price), but rather for embedded control where realtime requirements do not allow the slow interrupt response and I/O times seen in office applications. People who have only worked in data processing situations where millisecond response is considered fast really have no concept of how fast the response needs to be in realtime applications. We see it frequently on this forum. It would be nice to have a preemptive multitasking OS where interrupts are not held up while a task switch is being performed. I don't know enough about preemptive multitasking systems to know if that's possible. I did a cooperative multitasking realtime system for work a few years ago on a PIC16 where interrupts could be processed even during a task switch (which consisted of nothing more than a return to the cyclic executive main loop and a call of the next task).

A high-priority interrupt could be like something I've done many times for generating or sampling an analog signal on a very exacting interval, something that more-complex machines usually do with DMA and a separate signal engine of some kind (although that process, and the delay from the buffers involved, might be a problem sometimes too). Even on my 5MHz '02 workbench computer, I've exceeded 140,000 interrupts per second, and sampled audio at 44ksps, interrupt-driven by a VIA timer. The delay to start the ISR must be very short, and just as importantly, consistent, since there's no buffer between the data converter and the bus. Uncertainty in the timing constitutes jitter which results in distortion.

If a computer and OS are designed for a use that won't ever need such urgent interrupt service, that's understandable; but I would recommend making sure the processor itself can still do it if someone wants it to in a realtime design.

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


Top
 Profile  
Reply with quote  
 Post subject: Re: 65VM02
PostPosted: Mon May 22, 2017 3:04 am 
Offline
User avatar

Joined: Sun Dec 29, 2002 8:56 pm
Posts: 460
Location: Canada
The 6502 doesn’t have very much state to save on interrupt. One mechanism that could be used is dedicated internal interrupt stack rather than a return stack. This is especially helpful with a multi-tasking OS you don’t have to worry about how to switch stacks around during an ISR. The setting of the D register wouldn’t matter. If the internal stack is made wide, all the regs (a,x,y,p,pc) could be saved in a single cycle. The internal stack wouldn’t have to be very deep as it’s not likely that there’d be many nested levels of interrupts. For example RISC-V uses a four entry internal stack to save some of the processor state. For most ISR routines it’s not necessary and important to actually not mess with the state that got saved on stack. The reason why it wasn’t done this way originally is that it requires more hardware resources to do, but the resource cost isn’t huge.

_________________
http://www.finitron.ca


Top
 Profile  
Reply with quote  
 Post subject: Re: 65VM02
PostPosted: Mon May 22, 2017 3:13 am 
Online
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8538
Location: Southern California
That sounds perfect, Rob!

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


Top
 Profile  
Reply with quote  
 Post subject: Re: 65VM02
PostPosted: Mon May 22, 2017 6:19 am 
Offline
User avatar

Joined: Sun Dec 29, 2002 8:56 pm
Posts: 460
Location: Canada
One thing that’s present in the FT832 core (which has hardware to support tasks) is task vectoring on interrupt. Basically, when an interrupt occurs it can cause an automatic task switch which is very fast. I believe it’s faster than a 6502 interrupt IIRC. Rather than store the ISR address in the vector table the task id to switch to is stored there. Since the task id is only a 9 bit number the vector table can remain 16 bits wide, while the task’s pc can be located anywhere in a 32 bit address space as it’s read from the task table. (The task table is a dedicated 512 entry table that loads and stores in parallel the task state). For a small multi-tasking system using dedicated registers to store state instead of main memory is a simple and fast solution.

_________________
http://www.finitron.ca


Top
 Profile  
Reply with quote  
 Post subject: Re: 65VM02
PostPosted: Mon May 22, 2017 6:21 am 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
Quote:
The 6502 doesn’t have very much state to save on interrupt. One mechanism that could be used is dedicated internal interrupt stack rather than a return stack. This is especially helpful with a multi-tasking OS you don’t have to worry about how to switch stacks around during an ISR. The setting of the D register wouldn’t matter. If the internal stack is made wide, all the regs (a,x,y,p,pc) could be saved in a single cycle.

If the registers are already in a register file (which is the case for my core and the A, X, and Y registers), you can implement this stack using register windows. Just add an offset to the register index and you get a fresh set of registers for almost no additional cost. For P, PC it requires a bit more work, though.
Quote:
With the 65VM02 however, I'm expecting to have a multi-tasking OS. If you need to spend a long time doing something, that code would be a task rather than an ISR.

Many tasks have a structure like this:
Code:
loop:
    wait for event
    handle event

Those are perfectly suited for handling in a low priority interrupt, without having to deal with the heavier-weight mechanism of a task switch. It also saves you from having to allocate another stack. In most of my projects I use a non-preemptive task scheduler where tasks only switch whenever a task itself decides to wait for something. This makes the design a lot easier because you can freely modify shared variables without having to worry about some other task jumping in halfway during a critical operation. The disadvantage of a non-preemptive system is that it becomes harder to do real-time stuff, but I find that a combination of non-preemptive tasks, and multiple interrupt priorities works great to solve nearly all problems with a minimum of complications. One example I have is a I2C-based pressure sensor that needs to be read 1000 times per second. This is very easily solved by using a low priority timer interrupt, which then jumps into the (slow) I2C code.
Quote:
The 65c02 already has the I-flag and the SEI and CLI instructions. There is an extra bit available in the P register (what I was using previously for the T-flag that I no longer have). Maybe I could dedicate this to being another interrupt mask --- lets call it the L-flag (for low-priority interrupt mask), and provide two new instructions SEL and CLL for setting and clearing it.

What I would do is keep the single I flag for global interrupt enable/disable, and then keep two hidden bits for current priority. Make it so that an interrupt only happens if the I flag is set, and the interrupt priority is higher than current priority. The advantage is that you can simply enable/disable all interrupts with the CLI/SEI instructions, while still allowing nested interrupts. If you make two flags, and you want to disable interrupts for a critical section, you would have to do PHP, SEI, SEL, funny business, PLP. With the single flag, you just do SEI..funny business...CLI.


Top
 Profile  
Reply with quote  
 Post subject: Re: 65VM02
PostPosted: Mon May 22, 2017 7:05 pm 
Offline

Joined: Fri Jun 03, 2016 3:42 am
Posts: 158
Well, I redesigned the interrupts on the 65VM02 using ideas from all of you --- thanks for your input! :) --- the new document is attached.

My new design allows IRQ and NMI to interrupt the low-priority ISRs (NMI can also interrupt an IRQ ISR). So, NMI would be used for super-high priority interrupts, IRQ for high priority interrupts, and the other interrupts for lower-priority interrupts (the low-priority interrupts can't interrupt any other ISR at all).

GARTHWILSON wrote:
It would be nice to have a preemptive multitasking OS where interrupts are not held up while a task switch is being performed. I don't know enough about preemptive multitasking systems to know if that's possible. I did a cooperative multitasking realtime system for work a few years ago on a PIC16 where interrupts could be processed even during a task switch (which consisted of nothing more than a return to the cyclic executive main loop and a call of the next task).

The NMI and IRQ interrupts would not be held up while a task-switch is being performed --- the low-priority interrupts would be held up though, because they can't interrupt each other.

If I were programming a 65c02, I would use a cooperative multi-tasking OS similarly to your PIC16 program. Forth traditionally did use a round-robin cooperative multi-tasker because that is what Charles Moore wrote way back in the 1970s for his Kitt Peak work (I think that was a PDP11). This is a reasonable design that many people have used successfully.

On the 65VM02 however, I have the EXA instruction that can be used for obtaining a semaphore. This allows a preemptive multi-tasker. The idea is that any shared resource has a semaphore associated with it. A task obtains the semaphore (it may have to wait until another task releases the semaphore). While it has the semaphore it can access the resource and it can be guaranteed that no other task will access the resource at the same time. If a task-switch occurs while the task is in the middle of accessing the resource, and there is some other task waiting to access the resource too, the other task will find the semaphore already set to 1 by the first task and it will wait until the semaphore gets set to 0 before it can obtain the semaphore and the resource.

I've never used a preemptive multi-tasker, so all of this is new to me. It is a pretty interesting subject though --- I want the 65VM02 to support this --- I think that, if the 65VM02 is going to be used in the real-world, it would be expected to support this.

GARTHWILSON wrote:
A high-priority interrupt could be like something I've done many times for generating or sampling an analog signal on a very exacting interval, something that more-complex machines usually do with DMA and a separate signal engine of some kind (although that process, and the delay from the buffers involved, might be a problem sometimes too). Even on my 5MHz '02 workbench computer, I've exceeded 140,000 interrupts per second, and sampled audio at 44ksps, interrupt-driven by a VIA timer. The delay to start the ISR must be very short, and just as importantly, consistent, since there's no buffer between the data converter and the bus. Uncertainty in the timing constitutes jitter which results in distortion.

This is what IRQ would be used for. In the new design, IRQ can interrupt the ISRs for the low-priority interrupts. IRQ tied to a timer with a fast frequency will execute on a strict schedule without any jitter --- an example would be reading an analog>digital converter.

GARTHWILSON wrote:
If a computer and OS are designed for a use that won't ever need such urgent interrupt service, that's understandable; but I would recommend making sure the processor itself can still do it if someone wants it to in a realtime design.

The 65VM02 is intended to be used for hard real-time micro-controller programs. :-)

I wish I had thought of the 65VM02 in the early 1980s, but I was still in high-school at that time. The 65VM02 would have allowed computers such as the Commodore-64 to support a multi-tasking OS. How cool would that have been? 8) CP/M and MS-DOS would not have become popular --- who would want to use MS-DOS and its TSRs :twisted: when a real multi-tasking OS was available on the C64? --- the world would have been a better place!

Those days are long gone though. :cry: Now the only realistic use for the 65VM02 would be in a low-cost low-power micro-controller --- a step up from the 80c320, but a step down from the ARM --- somewhat of a narrow niche, but I think it could find some use in the real-world (the STM8 is currently in that niche).

This is the rewritten part of the document discussing interrupts:
Code:
These new instructions support the MIRQ interrupts:
MRTI                used to terminate MIRQ ISRs (similar to how RTI is used to terminate IRQ and NMI ISRs)
SEM                 sets the M-flag (this masks MIRQ interrupts, similar to SEI for IRQ)
CLM                 clears the M-flag (this allows MIRQ interrupts to occur, similar to CLI for IRQ)

These new instructions support the IRQ and NMI interupts:
ENTR                push A X Y to the return-stack, then move D to X, then set A Y and D to zero
EXIT                move X to D, then pull Y X A from the return-stack


Section 3.) the MIRQ interrupts

IRQ and NMI are the same as they were on the 65c02 --- they only push P and PC, and they end with RTI.
IRQ has a higher priority than MIRQ if they are both pending at the same time, and NMI is higher-priority than IRQ.
IRQ and NMI set the M-flag and the I-flag upon start --- so neither MIRQ nor IRQ can interrupt them.

There are four MIRQ interrupts in addition to the IRQ and NMI of the 65c02.
The lower MIRQx has a higher priority if there is more than one MIRQ pending at the same time.
MIRQ0   vector: $100
MIRQ1   vector: $102
MIRQ2   vector: $104    typically the UART that communicates with a desktop computer
MIRQ3   vector: $106    typically the heartbeat timer that does the task-switch

The MIRQ interrupts set A Y and D to zero so the direct-page is at $00 and the return-stack is at $100.
They then set the M-flag and push these registers:
PC      the old PC value, not the new PC that points to the ISR
P       the old P value, not the new P that has M-flag set
D       the old D value, not the new D that is 0
A       the old A value, not the new A that is 0
Y       the old Y value, not the new Y that is 0
They then execute the ISR.

The MIRQ ISRs should end in MRTI rather than RTI to undo all of this (6 bytes, rather than just 3 bytes).
The MIRQ ISRs can use A and Y freely, but they can't use X because it isn't saved and restored automatically.
If the MIRQ ISRs need to use X, then can start with PHX and end with PLX to save and restore X manually.

Most ISRs don't need to use X. They typically use A to hold data, and Y as a pointer into a circular buffer.
It is possible for MIRQ ISRs to be written in Forth rather than assembly-language.
In this case, X and IP need to be saved and restored manually. X and IP are set for a new Forth system.
Forth is pretty slow compared to assembly-language though, so writing ISRs in Forth is not recommended.
An ISR is short and simple --- assembly-language is not onerous --- Forth is for the tasks because they are big.
MIRQ3 is typically the heartbeat timer, and this does a task-switch, setting X IP and D for the new task.

Rather than work with a circular buffer, an MIRQ could be used to read or write files between the alternate-bank.
The FLDA and FSTA instructions are provided to allow the alternate-bank to be used as a RAM-disk.
The system may send and/or receive files over a UART while communicating with a desktop computer.

Note that S is pointing somewhere in the middle of page-one, but this varies every time an MIRQ interrupt happens.
This is one reason why MIRQ shouldn't interrupt each other --- they might clobber each other's return-stack.
The M-flag is set upon entrance to any ISR and it should be left set so one MIRQ doesn't interrupt another.
MIRQ ISRs can be interrupted by IRQ and NMI though --- assuming that the I-flag is clear, which it generally is.
The IRQ and NMI ISRs don't use the page-one return-stack at all, so they don't clobber the MIRQ ISR's return-stack.

The M-flag masks MIRQ interrupts. This is set upon start-up. Use CLM to clear the M-flag and SEM to set it.

The MIRQ interrupt vectors are in RAM, so you have to be careful to set them before a CLM is done in the start-up.
They are in the bottom of page one, so they should hopefully not clash with legacy programs' memory usage.

It is assumed that the I/O ports are all in page zero. This is why D gets set to zero in MIRQ interrupts.
The multi-tasking OS uses D as zero for its own work, and gives the tasks other D values.

IRQ and NMI ISRs should start with ENTR and end with EXIT as shown below:
    ENTR        ; push A X Y to the return-stack, then move D to X, then set A Y and D to zero
    ...         ; do the ISR --- use of the return-stack (JSR or PHA PHY PHX) is banned --- use of X is banned
    EXIT        ; move X to D, then pull Y X A from the return-stack
    RTI
The primary limitation is that the ISR can't use the return-stack at all.
This is because the return-stack is page-one that belongs to the MIRQ ISRs and S is pointing into the middle of it.
If an IRQ or NMI interrupted an MIRQ ISR and then used the return-stack, it would likely clobber the MIRQ ISR's data.
IRQ and NMI ISRs should be pretty short and simple, so they don't need to call subroutines.

Another limitation is that the X register can't be used in the ISR because it is holding the old D value.
If an IRQ or NMI ISR needs the X register, the X register can be temporarily held in a direct-page variable like this.
    ENTR        ; push A X Y to the return-stack, then move D to X, then set A Y and D to zero
    STX $BF
    ...         ; do the ISR --- use of the return-stack (JSR or PHA PHY PHX) is banned --- use of X is okay
    LDX $BF
    EXIT        ; move X to D, then pull Y X A from the return-stack
    RTI
Note that PHX and PLX can't save and restore X because use of the return-stack is banned in IRQ and NMI ISRs.
Also note that the ISR can't be written in Forth because use of the return-stack is banned in IRQ and NMI ISRs.
IRQ and NMI are high-priority interrupts (they can interrupt MIRQ ISRs) so they should be in assembly-language for speed.
The STX and LDX would not generally be done because they waste time, and speed is critical in high-priority interrupts.
A typical use for IRQ would be a timer set at a high frequency, and the IRQ reads an analog>digital converter (ADC).
Reading the ADC has to be done on a strict schedule, so IRQ would be used because it can interrupt the MIRQ ISRs.

IRQ or NMI should not be used for the heartbeat timer because we don't want to do a task-switch in the middle of an MIRQ ISR.
Typically MIRQ3 should be the heartbeat timer because it is the lowest priority of the MIRQ interrupts.
The heartbeat is low priority because the tasks aren't expecting to be on a strict schedule.
MIRQ2 is typically the UART to the desktop computer because this is usually pretty slow, and it is not a high priority.
MIRQ1 and MIRQ0 are for high priority I/O. IRQ and NMI are for extremely high priority I/O (these can interrupt MIRQ ISRs).

Note that MIRQ ISRs start with A and Y set to zero, and IRQ or NMI ISRs also have A and Y set to zero if they use ENTR.
This is "defensive design." A possible bug is that the programmer forgets to initialize A or Y before using them.
By having them always start as zero, the program will do the same thing everytime it is run (possibly a bug though).
If there is a bug, you find out early --- you don't have a program that sporadically fails, which is very bad.

Note that D is set to zero on start-up. Legacy programs should work unchanged because this is the same configuration as the 65c02.
The M-flag gets set in IRQ and NMI interrupts, but this won't affect legacy programs because this bit in P was unused on the 65c02.


Attachments:
File comment: redesigned interrupt system that allows NMI and IRQ to interrupt the low-priority ISRs
65VM02.txt [35.95 KiB]
Downloaded 68 times
Top
 Profile  
Reply with quote  
 Post subject: Re: 65VM02
PostPosted: Tue May 23, 2017 5:30 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
Hugh Aguilar wrote:
I wish I had thought of the 65VM02 in the early 1980s, but I was still in high-school at that time. The 65VM02 would have allowed computers such as the Commodore-64 to support a multi-tasking OS. How cool would that have been? 8) CP/M and MS-DOS would not have become popular --- who would want to use MS-DOS and its TSRs :twisted: when a real multi-tasking OS was available on the C64? --- the world would have been a better place!

By the late 1970s, preemptive multitasking was available in the form of UNIX. All of the targeted systems had the common features of memory protection and user/supervisor mode, which none of the Commodore eight bit machines had. A different microprocessor would not have mattered, as the eight Commodore designs from the VIC-20 onward were hobbled by the behavior of the video hardware, which was in constant contention with the MPU for bus time. A protected environment on such a machine would have been all but impossible to implement, since, in effect, two different processors were accessing the buses.

Anyone who is familiar with the hardware of systems capable of preemptive multitasking knows that the MPU is only part of the equation. What makes preemptive multitasking of the sort implemented with UNIX practical is hardware support for memory protection and different modes of operation. In modern systems, the MPU handles that ("rings of privilege," page tables, etc.). Back in the late 1970s and early 1980s, most systems had dedicated management hardware to enforce memory protection and the trapping of privileged instructions when executing in user mode. A few multitasking machines, most notably the Commodore Amiga, had no dedicated memory management hardware and relied upon careful operating system design to protect the kernel and critical system areas from the effects of dubious programming. However, the Amiga was a one-user system, unlike its contemporaries that ran UNIX, which were designed from scratch to support multiple users running multiple tasks. The Amiga kernel's only real threat was the user and if s/he were dumb enough to run a program that overwrote the kernel, stack, or other system area and crashed the machine (which people did do on occasion), oh well!

I'm not certain what your ultimate goal is with your 65VM02 design, but my curmudgeonly opinion is you will find that an intense focus on the microprocessor without considering how the rest of the targeted system will fit together is not going to produce a satisfactory result. A computer is much more than just an MPU. What about I/O? Oftentimes, the interfacing of I/O hardware to the system is much more complicated than interfacing the microprocessor. Although the 65xx peripheral devices may suffice in a uni-tasking environment, they will probably be inadequate in a multitasking situation, especially the 65C51 UART, which is a very "labor-intensive" device from the perspective of the microprocessor.

Also, the focus on Forth will likely narrow the attraction of your design to where it may not be of interest to those who would want to run an operating environment of which Forth would not be a part. The hardware design should not favor one operating environment over another, and should be sufficiently generalized to allow any kind of operating environment to be run, including one with a real-time kernel. Although I have no interest in Forth, I did design my POC V2 unit so it could run the Forth kernel if someone were so inclined to write one for the 65C816. Except for characteristics that are a natural result of using the 65C816 in native mode, the POC V2 hardware imposes no restrictions on what one can do, even to the point where the firmware can be completely mapped out of the system and replaced with whatever the user wants to load in its place. In fact, the I/O hardware can be mapped out as well, although that would tend to make for a useless system in most cases. :D

In following your topic, I'm getting the feeling you haven't fully defined what it is the 65VM02 is supposed to do that the 65C02 and 65C816 can't do. Am I misunderstanding?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: 65VM02
PostPosted: Tue May 23, 2017 6:41 am 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
I avoided so far any contribution to this topic as I am not speaking Forth nor I am willing to try it again - there are so many other brides that are appealing...

BigDumbDinosaur wrote:
Anyone who is familiar with the hardware of systems capable of preemptive multitasking knows that the MPU is only part of the equation. What makes preemptive multitasking of the sort implemented with UNIX practical is hardware support for memory protection and different modes of operation.
100% ACK. But I'm thinking all the talk so far didn't consider true (aggressiv or hostile) multitasking - only cooperative one.

BigDumbDinosaur wrote:
I'm not certain what your ultimate goal is with your 65VM02 design, but my curmudgeonly opinion is you will find that an intense focus on the microprocessor without considering how the rest of the targeted system will fit together is not going to produce a satisfactory result. A computer is much more than just an MPU. What about I/O? Oftentimes, the interfacing of I/O hardware to the system is much more complicated than interfacing the microprocessor. Although the 65xx peripheral devices may suffice in a uni-tasking environment, they will probably be inadequate in a multitasking situation, especially the 65C51 UART, which is a very "labor-intensive" device from the perspective of the microprocessor.
:D 98% ACK. I just wouldn't say your opinion is curmudgeonly. To me your words sounds "experience battered".

@Hugh:
Please don't misunderstand my words as offending - your work so far and your goal (as far as I understand it) is great - no doubt. And it is already an interesting contribution to the 6502 world. So don't hesitate - go on! :)


Top
 Profile  
Reply with quote  
 Post subject: Re: 65VM02
PostPosted: Tue May 23, 2017 6:54 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10975
Location: England
I'm not buying this argument that supervision and memory protection is necessary. It's on the lines of super-defensive engineering, of course, but sometimes too much defence makes for a lack of progress. It's perfectly possible to have multitasking with neither of those features - indeed, it's necessary for the environment not to be hostile, but recall that even the early multi-user Unix setups allowed for plenty of practical jokes because users were not in fact totally insulated. Most, in fact I think all, engineering environments I've worked in have also been "vulnerable" in this sense - one engineer can make a mess of another engineer's work, but that almost never happens. It turns out to be too defensive to have tight file system permissions and tight limits on compute resources.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 217 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8, 9, 10 ... 15  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: