65ISR
HughAguilar
Posts: 31
The 65ISR is a processor that I designed. People have said that it is similar in design to the P1 in that programming it would be similar.
It is like a 65c02. The 65ISR-chico version only has ISRs --- there is no main program. The 65ISR-abu version does have a main program.
In both cases, the ISRs or the main-program can't be interrupted --- they have to explicitly release control.
The ISRs release control when they finish. The main-program releases control after setting up a vector to allow it to restart again when it gets control back.
I invented this scheme --- nothing like this has been done before --- it might be a bad idea.
The 65ISR isn't directly related to the P1 though, so this may be too off-topic for the Parallax Forum. If so, let me know, and I won't post any further messages like this that aren't directly related to Parallax products.
It is like a 65c02. The 65ISR-chico version only has ISRs --- there is no main program. The 65ISR-abu version does have a main program.
In both cases, the ISRs or the main-program can't be interrupted --- they have to explicitly release control.
The ISRs release control when they finish. The main-program releases control after setting up a vector to allow it to restart again when it gets control back.
I invented this scheme --- nothing like this has been done before --- it might be a bad idea.
The 65ISR isn't directly related to the P1 though, so this may be too off-topic for the Parallax Forum. If so, let me know, and I won't post any further messages like this that aren't directly related to Parallax products.
Comments
In most MCUs main can defeat INTs with disable interrupt opcodes/flags, which seems more direct.
Using a vector to do the same thing, means you need to test the value of that vector, unless you use a vector plus some flag, in which case it is more like most MCUs....
I only briefly scanned your paper. I can't see how programming that would be in anyway similar to the Propeller. Except perhaps for the conditional execution idea.
Does the 65ISR exist in any form, Verilog, VHDL for an FPGA ?
The 65ISR-chico doesn't support subroutines --- it is a very simple processor --- I was inspired by Walter Banks' RS08 (mine has indexed addressing though, which helps a lot for circular buffers).
In the 65ISR-abu you also have a main-program, and you get to have subroutines. This is similar to the hub --- it oversees the operation of the ISRS --- it does stuff that is not time-critical, such as updating a display.
For the most part, you would not use subroutines anyway --- the 65ISR doesn't have a stack, so there are no local variables --- you use global variables for everything, which largely precludes having general-purpose code-libraries.
I have not programmed the P1 though --- I just read about it --- I may be misunderstanding how the P1 is programmed.
As for the conditional execution, I borrowed that idea from the ARM --- it is also done on the P1 and P2 afaik --- it is common.
The P1 seemed intriguing, but somewhat under-powered --- I never delved into that --- I might delve into the P2 though, as that is a very powerful processor.
No.
I originally designed the 65ISR as a way for me to learn Verilog --- the 65ISR is super-simple --- it is simpler than the 65c02, which is the typical first-ever project for Verilog students.
I still haven't learned Verilog though --- I haven't really delved into it.
Later on I designed another processor, the TOYF that is simpler than the 65ISR, but is also more powerful (it is 16-bit and should out-perform the MSP430 that is the most common 16-bit processor in use today).
It is simpler because there are no multi-cycle instructions --- every instruction executes in one clock cycle --- every instruction does only one super-simple operation.
It is VLIW, with up to 3 instructions executing concurrently in one cycle --- it is similar to the MiniForth processor that I wrote the development system for when I was employed at Testra --- the MiniForth (now called RACE) was for motion-control and the TOYF would be for motion-control too.
The TOYF doesn't have interrupts at all, so you have to use a paced-loop --- this is okay for motion-control.
The 65ISR doesn't have a return-stack, so there is no place to store information about how to return.
Because of this, ISRs can't be interrupted. The main program can release control and let an ISR execute --- it has to store information about how to return in global variables.
The 65ISR is a very simple processor! By comparison, the 65c02 is a mini-computer. The 65ISR is simpler than the 6805 that is the simplest processor still in use (assuming that the 6805 is still in use somewhere).
The 65ISR doesn't have a data-stack either --- everything is done in global variables.
To a large extent, I designed the 65ISR as a challenge to myself --- the challenge is to write a Forth system that converts all stack operations into operations on global variables --- Walter Banks did this with his C compiler for the RS08.
Reread the document --- there is no test of any vector or flag.
The 65ISR-chico is purely event-driven. This has been done before.
The 65ISR-abu does have a main-program --- the way this works is my invention --- see the M-flag in the processor status register, which no other processor has (this is tested by hardware, not by software).
Alternatively one could disable specific interrupts by writing to the interrupt controllers registers.
All of this is required so that the main program loop can share data safely with the interrupt handler code.
The main program can share data with ISRS because the main program only releases control voluntarily --- it can't be interrupted --- when it releases control, the highest-priority ISR executes.
If there is no ISR pending, then the main-program can regain control.
The main-program can release control in such a way that it won't execute again until at least one ISR has executed, or in such a way that if no ISR is pending the main-program will regain control immediately.
My 65ISR design is original --- you aren't going to grok it by glancing over the document for one minute.
If you want a debate on parallel microprocessor processing you have certainly come to the right place!
It reminds me a little bit about the workings of a realtime minicomp system I'm familiar with, from old, so it got me interested.
Admittedly "required" is a bit strong as it is possible to share data between a background loop and interrupt handler without disabling/halting either. Using lock free data sharing methods, like cyclic buffers and such. In the general case though such mutual exclusion is required to prevent data races when sharing data between concurrent tasks. Be they interrupt handlers, threads, or even separate processors sharing memory. Which is why our processors have a instructions to disable interrupts provide hardware locks etc. That is exactly the same as when enabling/disabling interrupts in a background loop. The main program voluntarily executes a CLI (for example) and then any pending interrupt handler will run. If there is no pending interrupt the main loop continues. That I find interesting.
If I understand what you are saying correctly, effectively in that case there is no background loop anymore. or we could say everything has become an interrupt handler. The whole system is event driven.
This is an idea I have thought about from time to time, why not build a purely event driven processor? Nothing happens unless an event occurs. If event handlers all have the same priority, they run to completion and cannot interrupt each other, then we have the "event driven" programming model, as seen in Javascript and other languages, implemented directly in hardware. That implies the hardware supports an event queue so that events don't get forgotten.
Getting rid of interrupts and threads with an event driven programming model makes reasoning about the correctness of programs much easier.
One might ask: What about those high speed events that we have interrupts for?
Well, given one is building ones own hardware, in FPGA or whatever, to do this then peripherals would be built in logic instead of software, they would be equipped with sufficient buffering to prevent data loss. And of course if some external event really needs low latency attention it gets its own dedicated processor. As in the Propeller concept.
These thoughts of hardware supporting the "event driven" programming model started to grow on me years ago when working on flight controllers at Lucas Avionics. They had a language called Lucol that had no background loop concept (Actually Lucol had no concept of loops at all, but that is another story). Then again when discovering the wonders of Javascript and it event driven programming model.
At one point I was petitioning for such an event model in the P2, but it ended up using good old fashioned interrupts.
I'll certainly be reading your paper properly when I have a some time, see if I can understand it more clearly.
Hey how come I never heard of anycpu.org before? Lots of interesting discussion over there, and names I recognize from here.
I read some of your 65ISR thread there. Seems I was right, we are on the same page, event driven programming is what you have in mind.
I think I see more clearly what you have in mind from those discussions. Interesting stuff.
One comment I read there caught my eye "a custom HDL is not possible anymore". Well not quite, the guys designing RISC V cores at Berkeley and elsewhere use an HDL they invented called Chisel. Then there is SpinalHDL, http://spinalhdl.github.io/SpinalDoc/ which I have been playing with recently. Both these leverage the power of Scala and are much nicer to work with than Verilog.
Meanwhile we have the Free and Open Source HDL tool chain YoSys http://www.clifford.at/yosys/ which at least synthesizes bitstreams for Lattice devices.
The traditional way is to have a main-program that can be interrupted, and ISRs that can be interrupted by higher-priority ISRs.
If you do this, you get low interrupt-latency because the high-priority ISRs don't have to wait for a low-priority ISR to finish and they don't have to wait for the main-program to voluntarily relinquish control --- they just execute immediately.
The way my 65ISR works, is that ISRs can't be interrupted, so a high-priority ISR may have to wait for a low-priority ISR to finish before it can execute. Also, the main-program has to relinquish control voluntarily, which may not happen as soon as one would wish (the programmer puts BRK instructions in his code like punctuation that give ISRs a chance to execute, but how often he does a BRK is up to him and the frequency of BRKs may vary a lot).
So, my system might have too much interrupt-latency if the programming isn't done carefully to avoid this, or possibly even if the programming is done carefully just because the application is too complicated for my simple scheme to work well.
The advantage of my system is that, overall, fewer clock cycles are burned. This is because I don't spend any time saving and restoring registers to the return-stack (I don't even have a return-stack). By comparison, the STM8 takes 11 clock cycles to save all the registers when entering an ISR, which seems like quite a lot to me; in addition to burning a lot of clock cycles, this is also a lot of interrupt latency. The 65ISR might be a good choice for low-power devices that need to minimize clock-cycles to save the battery. The application would need to be fairly simple --- if you have a lot of interrupt sources with varying levels of priority, the 65ISR might get into trouble in regard to high-priority ISRs failing to execute in time resulting in data loss.
The 65ISR-chico is a very tiny processor! It would typically be programmed in assembly-language. It doesn't support subroutines, so you can't have an HLL (High Level Language), although a BASIC might be realistic. This would be for embedded devices that you don't really think of as being computer-controlled. These kinds of devices may be very high volume --- this could make me rich --- an example would be if one of the car manufacturers chooses it for controlling the signal lights in a car (it would need I2C to do that, I suppose). It is intended to be competitive with the PIC16 chips (iirc, the PIC16 was used in the BASIC Stamp).
The 65ISR-abu is a bigger processor. It supports subroutines and a main-program, so you can have an HLL (I would go with Forth, but C or Pascal would also be realistic and possibly easier to implement). The 65ISR-abu can address 16MB of memory, so it is competitive with the STM8 for applications that need to hold a lot of data. It has the W register, so it is going to be a lot more efficient for any program that has any complicated data-structure (the 65ISR-chico only supports 256-byte arrays or buffers).
The 65ISR-abu can execute any 65ISR-chico program. A person could start out with the 65ISR-chico and then, if it proves to be too limited, upgrade to the 65ISR-abu. He can keep most of his existing software and only rewrite what is necessary.
I'm dubious that anybody would be interested in the 65ISR --- the PIC16 and STM8 are pretty good 8-bit processors, and the 16-bit MSP430 is also going strong --- there aren't many people who are unhappy with the current choices and want something better.
Interesting. So what you have there is sort of like like a cooperative multi-tasking scheduler but done in hardware. Your BRK instruction sounds like the "suspend" function or whatever such a software scheduler would have.
Certainly that will result in high latency.
STM8 may take 11 clocks or whatever to get into an interrupt routine but surely that is nothing compared to your set up. Unless you have BRKs every few instructions. But then that impacts performance.
There are so many trade offs to be made in CPU design.
Now, the fun of it would be getting that into an FPGA and seeing how small it really is and how it flies for some real programs.
I read on the cpu forum that you were not into Verilog, perhaps you are by now, as a software engineer I suspect you would be happier with designing the hardware in a higher level language and I suggest SpinalHDL. http://spinalhdl.github.io/SpinalDoc/ Spinal lets one design hardware in the luxury of a real software engineering language.
It won't impact the performance very much either --- it is a pretty fast instruction, and the BIRQ ISR generally holds only a single RTI (unless there is a debugger in there, but that wouldn't be done in production code).
The 65ISR-chico doesn't have a main-program at all --- the 65ISR-abu applications may not have a main-program either, or at least will have only a short one that doesn't do much.
One of the trade-offs to be made is how complicated your processor is.
A 8-bit accumulator
Y 8-bit index register
W 16-bit word register unsupported in the 65ISR-chico
PC 16-bit program counter 12-bit in the 65ISR-chico: 1111,xxxx,xxxx,xxxx
P 6-bit processor status flags
By comparison, this is the MC6805:
A 8-bit accumulator
X 8-bit index register
S 6-bit return-stack
PC 13-bit program counter
P 8-bit processor status flags
So, my 65ISR-chico has fewer registers than the MC6805.
Also, I have better support for circular buffers than the MC6805.
Also, I have better support for 1-bit data than the MC6805.
Also, the MC6805 had a lot of useless addressing-modes, such as 16-bit absolute, which I don't have (I only have 8-bit absolute for accessing zero-page global variables).
All in all, the 65ISR-chico is a very tiny processor!
It addresses more memory than the PIC16 though, and it has the page,Y addressing-mode that is useful for 256-byte arrays or circular buffers.
The 65ISR-abu has a W register. It is faster at accessing blocks of memory using W than the 65c02 is using (zp) or (zp),Y --- it would be slower though, for copying blocks of data because W would have to be reloaded repeatedly with the two pointers.
The 65ISR is an experiment in designing a tiny processor that is still useful. The goal was to be smaller than the MC6805 but more powerful.
I have my TOYF processor design that is a big powerful processor --- that has a completely different goal.
No, this is going to have to be a hobby project for fun.
I had been contemplating how to build my own CPU for decades. Perhaps using good old TTL chips, perhaps in an FPGA. Just a challenge to myself. I could never pin down anything concrete.
So now I'm cheating, I want to take a ready made instruction set, and a simple ready made CPU core design outline, and see if I can implement it and get in running in FPGA.
The instruction set architecture is the RISC V: https://riscv.org/
The core outline design is the single stage Sodor from Berkeley: https://github.com/ucb-bar/riscv-sodor/blob/master/doc/1stage.pdf
My HDL efforts so far are : https://github.com/ZiCog/sodor-spinal
The encouragement for me here is that by adopting RISC V the the compilers and other tools are already available. Dealing with HDL and FPGA is challenge enough for now.
Perhaps after that I'll get back to the idea of a small, simple 8 bitter.
OTOH, you are putting the 65ISR down more than it deserves to be put down.
I didn't bother watching that youtube video, but I am aware that there are a lot of processors around 5 cents in price. None of them compare to the 65ISR. They typically have 128 bytes of RAM and one 8-bit accumulator, and the only addressing modes they support are inherent, immediate, and zero-page absolute. The PIC16 is the leader here.
The 65ISR-chico would typically have at least 1KB of RAM, and it supports circular buffers. The 65ISR-abu can address up to 16MB of memory. This is a different category.
I have read about the RISC-V processor. I was not impressed. I think that my TOYF design is better.
I have no interest in using compilers and other tools that other people have written --- my interest is in writing this myself --- dealing with HDL and FPGA is just a chore that I have to do to obtain a processor, but is not something that I have any interest in.
I don't mean to put down the 65ISR at all. We all have paper designs for all kind of things that are worthy of discussion. I would be interested to hear why.
Remember the RISC V is not a processor. It is only a specification for an instruction set. One can implement that specification with whatever processor architecture one likes. I think you are in good company here. Chip Gracey likes to plough his own furrow. Building the Propeller chip and it's programming language and IDE from the ground up. And again with the P2.
At the end of the day the proof of the pudding is in the eating. One has to suffer the chore of implementation so that people can taste the product.
They also complicate the job of the programmer a lot because interrupts can occur at any time. The programmer has to use SEI and CLI to bracket blocks of code in the main-program that can't be interrupted. This is not much of an improvement over punctuating the main-program with BRK as required in the 65ISR-abu.
Also, if the main-program can be interrupted at any time, the ISR to be safe has to save and restore all of the registers because it doesn't know what is in use and what is not. By comparison, with the 65ISR-abu the programmer knows when BRK is being done and he just does this when there is no context to save and restore, which happens often (or he does his own save-and-restore if he can't find a place in which A Y W and P are not being used).
An alternative plan for the 65ISR-abu is to have interrupts. I still don't think a return-stack is worthwhile though. I would have shadow registers: A' Y' W' and P' that get swapped in for the ISR to use. This allows the main-program to get interrupted, so BRK is no longer needed. ISRs still can't get interrupted (at least not without a second level of shadow registers), so there could still be a problem with a high-priority interrupt needing to wait for a low-priority interrupt to finish before it can start --- this should not be much of a problem because every ISR finishes pretty quickly (because I have a lot of support for circular buffers).
This is a possible upgrade. This would significantly increase the complexity of the 65ISR-abu, possibly necessitating a bigger and more expensive FPGA chip. I won't consider this upgrade until the current plan has proven inadequate.
So, I have to learn an HDL and implement it. The 65ISR-chico is pretty simple --- other than the MC6805, there is no easier first-project.
The TOYF might be easier to implement than the 65ISR-chico. The TOYF is VLIW, which is a complication, but in many ways it is simpler than the 65ISR --- the TOYF instructions all execute in one clock cycle, and the TOYF is Harvard so making each opcode execute in one clock cycle should be easy --- the 65ISR instructions are all multi-cycle (the STM8 has one-cycle instructions, but that seems very difficult to implement; I would more likely have two-cycle instructions like the 65c02).
You would not believe how much debate about interrupts has gone on here over the years. You see the P1 has no interrupts. It does not need them as it has 8 cores to dedicate asynchronous external events. This makes programming the P1 gloriously simple, even in assembler. It makes mixing and matching of software objects form various sources into a project very easy as they don't fight with each other over processor time. When the idea to put interrupts into the P2 came up there was a lot of discussion about it.
I would not worry about the 65ISR getting big. Even the smallest FPGAs now a days can comfortably contain a 32 bit RISC V with it's 32 registers.
Now that is a terrible example, but whatever.
The Prop is weird in that it executes code from it's registers, all 496 of them. Entire programs can run without ever using other memory space. Is there any other processor do that?
Of course one can look at this in two ways:
1) The Prop has 512 registers that it can use for data or code.
2) The Prop has no registers (Except the PC). It is a memory to memory architecture.
Either way I agree, not needing all that load/store stuff to do anything makes programming in assembler so simple.
I think i'll allow aliasing registers locally for increased readability. It'll look a little bit like this (code is slightly different but whatever). Note the strange syntax that comes from using Ruby as, essentially, a macro language. Sadly, eliminating the colons from non-register label names would require some rather annoying code.
Also frick i wrote a wall of text. I should probably start my own thread about this instead of going 'round threadjacking.