Some people claim thar the 6502 is a RISC processor.
-
The idea with the 6502 was that Zero Page of the system RAM has slightly faster access times over the rest of memory.
This means its generally used as 256 register-like locations. Not as fast a real register but better than the rest of main memory.
Not ideal of course but it was a pragmatic solution for the technology and the time it was designed.
The family history between the 6502 and ARM isn't that surprising given the team that designed and prototyped the first ARM CPU
@simonzerafa @root42
Yes, that was a great feature, especially with the indirect indexed by Y addressing mode to use two consecutive zero-page bytes as an operand pointer, but it's still a CISC one-address architecture.
I'll agree that zero page functions _almost_ like general registers, but only._almost_. Everything still has to go through the accumulator. (Or, for just moving data, through X or Y).
It definitely gave a good boost in both speed and code density. -
@brouhaha @phloggen I read somewhere that when designing the ARM, one of the things that had impressed Acorn about the 6502 was the low interrupt latency, which had given the BBC micro features like background print buffering. They gave the ARM the FIQ mode with 7 private registers, although AFAICT this seems to rarely get used on modern devices.
@simonzerafa -
I dont know how you get the PDP-18 under 18 instructions ?
It's true that they come in 8 groups of instructions, but many inside the groups are distinct instructions which do wildly different things ?
-
I dont know how you get the PDP-18 under 18 instructions ?
It's true that they come in 8 groups of instructions, but many inside the groups are distinct instructions which do wildly different things ?
@phloggen
Only one instruction, OPR, does multiple selectable things, and it does them in parallel as much as possible, so it's often considered to be a single zero-operand instruction. -
Some people claim thar the 6502 is a RISC processor. It's not.
Hill I'll die on: The 6502 is about as unRISCy as a 4500 transistor 8-bit CPU can possibly be. It has over a dozen addressing modes, and is not orthogonal at all.
That says nothing about whether the 6502 is good or bad. In my opinion it was/is quite good for a lot of things, but not necessarily best for everything. It was, however, absolutely brilliant for the time it was introduced (late 1975).
@brouhaha the big benefit of the 6502 was it was pretty affordable but still pretty capable. -
The DG Nova was the first RISC, and anybody who wants to argue otherwise must bring an architecture with less than 18 instructions to the debate.
@phloggen
SSEM, 7 instructions, 1948 -
@phloggen
Only one instruction, OPR, does multiple selectable things, and it does them in parallel as much as possible, so it's often considered to be a single zero-operand instruction.I dont buy it
The PDP-8 has far too many "you just have to know this" footnotes.
Compare that to the Nova which is almost entirely orthogonal, for instance all ALU instructions taking the same options. and having the same skips.
-
The DG Nova was the first RISC, and anybody who wants to argue otherwise must bring an architecture with less than 18 instructions to the debate.
-
@brouhaha @phloggen I read somewhere that when designing the ARM, one of the things that had impressed Acorn about the 6502 was the low interrupt latency, which had given the BBC micro features like background print buffering. They gave the ARM the FIQ mode with 7 private registers, although AFAICT this seems to rarely get used on modern devices.
@simonzerafa@kbm0 @brouhaha @phloggen @simonzerafa FIQ type functionality was not new by then. 6809 has it for example. A lot of ARM is borrowed. Its how they mixed the ingredients.
-
@kbm0 @brouhaha @phloggen @simonzerafa FIQ type functionality was not new by then. 6809 has it for example. A lot of ARM is borrowed. Its how they mixed the ingredients.
@etchedpixels @kbm0 @brouhaha @phloggen
The 6809 is somewhat a better CPU than the 6502 in many ways and yet it's still impressive what the less capable 6502 can do.
-
@etchedpixels @kbm0 @brouhaha @phloggen
The 6809 is somewhat a better CPU than the 6502 in many ways and yet it's still impressive what the less capable 6502 can do.
@simonzerafa @etchedpixels @kbm0 @brouhaha @phloggen I learned Z80 first but prefer 6502. On one occasion I had to code the same thing for both, which was, interesting.
-
@simonzerafa @etchedpixels @kbm0 @brouhaha @phloggen I learned Z80 first but prefer 6502. On one occasion I had to code the same thing for both, which was, interesting.
@revk @etchedpixels @kbm0 @brouhaha @phloggen
I've since learned that the Z80 was a very capable CPU but somewhat hamstring by the platforms that used it
No such issues with 6502 based CPU platforms
-
@revk @etchedpixels @kbm0 @brouhaha @phloggen
I've since learned that the Z80 was a very capable CPU but somewhat hamstring by the platforms that used it
No such issues with 6502 based CPU platforms
@revk @etchedpixels @kbm0 @brouhaha @phloggen
It's been possible through, dark arts and necromancy, to add a protected mode to the Z80, which would have been very cool in 1989
GitHub - Andy18650/HEC-Model-Z1: A Z80 computer with protected mode support
A Z80 computer with protected mode support. Contribute to Andy18650/HEC-Model-Z1 development by creating an account on GitHub.
GitHub (github.com)
-
@revk @etchedpixels @kbm0 @brouhaha @phloggen
It's been possible through, dark arts and necromancy, to add a protected mode to the Z80, which would have been very cool in 1989
GitHub - Andy18650/HEC-Model-Z1: A Z80 computer with protected mode support
A Z80 computer with protected mode support. Contribute to Andy18650/HEC-Model-Z1 development by creating an account on GitHub.
GitHub (github.com)
@simonzerafa @revk @kbm0 @brouhaha @phloggen it was done in the 1980s by Morrow
-
@revk @etchedpixels @kbm0 @brouhaha @phloggen
I've since learned that the Z80 was a very capable CPU but somewhat hamstring by the platforms that used it
No such issues with 6502 based CPU platforms
@simonzerafa @etchedpixels @kbm0 @brouhaha @phloggen 6502 BRK was uses creatively by BBC Micro as I recall.
-
@simonzerafa @etchedpixels @kbm0 @brouhaha @phloggen 6502 BRK was uses creatively by BBC Micro as I recall.
@revk @simonzerafa @kbm0 @brouhaha @phloggen BBC uses JSR vectors in top of memory BRK on classic 6502 is buggy and cannot be combined reliably with interrupts so it's not really used for anything serious
-
@revk @simonzerafa @kbm0 @brouhaha @phloggen BBC uses JSR vectors in top of memory BRK on classic 6502 is buggy and cannot be combined reliably with interrupts so it's not really used for anything serious
@etchedpixels @simonzerafa @kbm0 @brouhaha @phloggen Yeh I may be misremembering, to be honest, long time ago.
-
R relay@relay.infosec.exchange shared this topic
-
@etchedpixels @simonzerafa @kbm0 @brouhaha @phloggen Yeh I may be misremembering, to be honest, long time ago.
@revk @simonzerafa @kbm0 @brouhaha @phloggen some 680x machines use SWI this way (equivalent of BRK) but BRK is really limited to dropping into the debugger until 65C02 annoyingly as I did want to use BRK for Fuzix syscalls on 6502
-
@simonzerafa @etchedpixels @kbm0 @brouhaha @phloggen I learned Z80 first but prefer 6502. On one occasion I had to code the same thing for both, which was, interesting.
@revk @simonzerafa @kbm0 @brouhaha @phloggen carry flag always gets me on 6502 when switching the CPU I am working with 6800 series, 8080 series and most others it's the other way around on subtract
-
@etchedpixels @simonzerafa @kbm0 @brouhaha @phloggen Yeh I may be misremembering, to be honest, long time ago.
@revk @etchedpixels @simonzerafa @kbm0 @brouhaha @phloggen By default on the Acorn 8-bit OS, the IRQ/BRK vector (0xfffe) redirects into ROM, which then splits it depending on the I flag.
If it is a BRK, then it will pull the calling address from stack and store the following address in 0x00ED and 0x00FE and then jump to the code pointed to by 0x0202. By default this will print the null terminated ASCII message after the BRK.
For example:
