View unanswered posts | View active topics It is currently Sun Sep 22, 2019 12:10 pm



Reply to topic  [ 36 posts ]  Go to page Previous  1, 2, 3
 65ISR 
Author Message

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1257
[oops, crossed in the post]

Ah, you have a divstep Hugh - that's something I keep coming back to, as a nice compromise between division-by-hand and multi-cycle-division in hardware. (Same for multiply, in the case that the FPGA doesn't offer multipliers.)

Arlet's 6502 appeared fully formed (as Mike just noted), but I did help with extending it to 65c02, and that turned out to be satisfyingly straightforward:
http://forum.6502.org/viewtopic.php?f=10&t=4224
That said, it is very much a 6502, whereas a microcoded 6502 might be more amenable to be being reshaped to support a different instruction set.

It is indeed Verilog - I speak both Verilog and VHDL, in very limited ways, but I do prefer Verilog. I think most toolchains support both, and support mixed designs too, so it's not such a big deal.

Yes, of course you're right, a PLD or CPLD is a very limited substrate for a CPU, and to make really good use you might even need to bear in mind exactly how it's implemented. I think the original line from PAL to GAL to PLD to CPLD uses PLA type architecture, whereas all but the first FPGAs use a logic cell architecture. There are some modern CPLD-type offerings which are more like mini-FPGAs than the older CPLDs were. (But this sketch might not be accurate! It sounds consistent with your sketch though.)

An interesting choice to make interrupts more of a polled feature. I think it's good to explore different ideas, so it will be interesting to see how that one plays out.


Sun Sep 24, 2017 6:27 am
Profile

Joined: Sun Jul 23, 2017 1:06 am
Posts: 93
BigEd wrote:
Ah, you have a divstep Hugh - that's something I keep coming back to, as a nice compromise between division-by-hand and multi-cycle-division in hardware. (Same for multiply, in the case that the FPGA doesn't offer multipliers.)

Is it true that a PID only needs addition and multiplication, but not division?

BigEd wrote:
Arlet's 6502 appeared fully formed (as Mike just noted), but I did help with extending it to 65c02, and that turned out to be satisfyingly straightforward:
http://forum.6502.org/viewtopic.php?f=10&t=4224
That said, it is very much a 6502, whereas a microcoded 6502 might be more amenable to be being reshaped to support a different instruction set.

It would likely be easier to start with a micro-code system and retrofit it to run the 65ISR. This could get the thing working more quickly --- then upgrade to hard-code later on to make it faster.

BigEd wrote:
Yes, of course you're right, a PLD or CPLD is a very limited substrate for a CPU, and to make really good use you might even need to bear in mind exactly how it's implemented. I think the original line from PAL to GAL to PLD to CPLD uses PLA type architecture, whereas all but the first FPGAs use a logic cell architecture. There are some modern CPLD-type offerings which are more like mini-FPGAs than the older CPLDs were. (But this sketch might not be accurate! It sounds consistent with your sketch though.)

Testra wrote their own HDL in Forth --- Lattice Design Language (LDL) wasn't adequate for building a processor on their PLD --- that was in 1994; nowadays you can't write your own HDL because the low-level information isn't available for the FPGA, so you have to use Verilog or VHDL (Testra uses VHDL on their RACE, which is the upgraded version of the MiniForth).

BigEd wrote:
An interesting choice to make interrupts more of a polled feature. I think it's good to explore different ideas, so it will be interesting to see how that one plays out.

Well, the programmer has to punctuate his main-program with POL instructions pretty frequently, so the main-program doesn't hold control for long. The assumption here is that the main-program is very low-priority --- do something that isn't very time-critical, such as keep the display updated --- the main-program would oversee the work being done by the IRQx ISRs, but not do any heavy-lifting itself.

Some systems may not have a main-program at all --- be entirely event-driven. :shock:


Sun Sep 24, 2017 12:10 pm
Profile

Joined: Sun Jul 23, 2017 1:06 am
Posts: 93
Hugh Aguilar wrote:
BigEd wrote:
An interesting choice to make interrupts more of a polled feature. I think it's good to explore different ideas, so it will be interesting to see how that one plays out.

Well, the programmer has to punctuate his main-program with POL instructions pretty frequently, so the main-program doesn't hold control for long. The assumption here is that the main-program is very low-priority --- do something that isn't very time-critical, such as keep the display updated --- the main-program would oversee the work being done by the IRQx ISRs, but not do any heavy-lifting itself.

Some systems may not have a main-program at all --- be entirely event-driven. :shock:

Note that I don't have a return-stack:
Code:
JSR     #word           move PC+2 to W >> do JMP                                            unsupported in the 65ISR-chico
RTS                     move W to PC                                                        unsupported in the 65ISR-chico

A subroutine can keep the return-address in W. This only works if it doesn't call any other subroutines, and it doesn't use W for any data internally. If the subroutine can't keep the return-address in W, then it saves W to a zero-page vector with STW and at the end it does a JMP through that vector instead of RTS. I got this idea from the ARM that uses R14 as a link register (also, I had a job once writing IBM370 assembly-language, and it does something similar, although my memory is somewhat foggy on the details of that processor).

So, the subroutine could save the return-address in MIRQ-VECTOR and then do an RTI at the end. This would allow it to use W for data, but would not allow it to call another subroutine that also saves the return-address in MIRQ-VECTOR (it could call a subroutine that holds the return-address in W). This means that POL is not needed! No time at all is being wasted, because the return-address had to be saved somewhere anyway, so the code is the same size as before (actually, slightly smaller because RTI is used rather than JMP zadr).

Essentially, we have three kinds of subroutines:
  • primitive --- these hold the return-address in W and end with RTS
  • secondary --- these hold the return-address in MIRQ-VECTOR and end with RTI
  • tertiary --- these hold the return-address in a zero-page vector that they own (not used by other subroutines) and end in JMP indirect.
All in all, I don't think my scheme will slow down the main-program very much. I do have to punctuate the main-program with POL instructions, but that is not going to slow things down much. If the main-program is calling secondary subroutines, then this is just as good as POL and doesn't take any extra time.

The big question is if interrupt-latency will be too much. The main-program is holding control for a while (maybe 10 to 20 instructions) and blocking the IRQx interrupts during this time.

If the main-program does a BLK prior to doing POL then interrupt latency will be very little. This is similar to a WAI on a traditional processor --- the processor goes into a low-power wait mode --- when an IRQx trips, response is very fast because no registers need to be saved and restored at all.

So, when programming the 65ISR, you want to do as little as possible in your main-program, or at least punctuate it with POL pretty frequently, so the main-program doesn't block the IRQx interrupts for too long. You also want your IRQx ISRs to be pretty short, so a low-priority ISR doesn't block a high-priority ISR for too long.


Sun Sep 24, 2017 7:19 pm
Profile

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1257
Yes, I like link registers. I think I truly understood the purpose when were making the OPC machines - a link reg is a nice minimal mechanism for a subroutine, and it avoids complex jsr/rts instructions. The subroutine itself can manage a stack, if it wants to. Or, as in your case, a not-stack, which means you have subroutines but no recursion.


Sun Sep 24, 2017 7:40 pm
Profile

Joined: Sun Jul 23, 2017 1:06 am
Posts: 93
Hugh Aguilar wrote:
Essentially, we have three kinds of subroutines:
  • primitive --- these hold the return-address in W and end with RTS
  • secondary --- these hold the return-address in MIRQ-VECTOR and end with RTI
  • tertiary --- these hold the return-address in a zero-page vector that they own (not used by other subroutines) and end in JMP indirect.

This was not correct! :oops:

I have a new document available. The design of the processor is the same as before.
I just added another section of documentation that explains how subroutines work. I had been confused on the subject.
Also, some people reading the document were confused about the whole thing (I received emails indicating confusion).
Hopefully with this section's explanation the design will be more clear.

Here is a snippet:
Quote:
We have four kinds of subroutines:

fast-ISR-subroutines
These hold the return-address in W and they end with RTS.
These can't use W for data, and they can't call other subroutines.

slow-ISR-subroutines
These hold the return-address in a zero-page vector that they own (not used by other subroutines) and end in JMP indirect.
These can use W for data and they can call fast-ISR-subroutines or slow-ISR-subroutines.

fast-main-subroutines
These hold the the return-address in MIRQ-VECTOR and end with RTI.
These can use W for data and they can't call other subroutines. They can't use POL internally.

slow-main-subroutines
These hold the return-address in a zero-page vector that they own and end in JMP indirect.
These can use W for data and they can call fast-main and slow-main subroutines. They can use POL internally.


Attachments:
File comment: same processor design --- more documentation
65ISR.txt [36.46 KiB]
Downloaded 251 times


Last edited by BigEd on Mon Sep 25, 2017 5:18 am, edited 1 time in total.

(remove extra layer of quoting)

Mon Sep 25, 2017 1:17 am
Profile

Joined: Sun Jul 23, 2017 1:06 am
Posts: 93
Well, I've begun work on the assemble/compiler. :-)

I have an upgraded design (attached).

I added more support for the 1-bit variables. This may be the primary feature of the processor.

I also added some more support for working with files in high 64KB banks. There are some other minor changes as well.

I also changed the way MIRQ works --- it is essentially the same idea as before --- just a minor change to allow for support for a debugger (I wrote a source-level single-step debugger for the 65c02 about 25 years ago, that was roughly comparable to Turbo Debugger for MS-DOS that I was familiar with).
I don't actually like debuggers. I prefer Forth's interactive console. A lot of people like debuggers though, so I provided support in the 65ISR for this.
I want the 65ISR to not be Forth-centric, but to also support C and Pascal, etc..

This is not a hard-and-fast design --- as I continue working on the assembler/compiler it may change again.


Attachments:
File comment: upgrade primarily in regard to the 1-bit variables
65ISR.txt [41.9 KiB]
Downloaded 269 times
Thu Oct 12, 2017 4:10 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 36 posts ]  Go to page Previous  1, 2, 3

Who is online

Users browsing this forum: No registered users and 1 guest


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:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software