Discussion: What would be the point of a 65xx HAL?

[tokafondo]

Thanks again for all your reading and patience.

If I would had wanted to build a thing like a new processor, I would had titled the thread with the right subject.

But the subject is about discussing about the concept of separate the machine code used in 65xx processor from the hardware that implement that machine code, having an abstraction in between.

Is HAL the right term? It seems not to.

I will try to explain once more:

The internal architecture of a i8086 is different from the one in a i80486, which itself is different from Pentiums, and so. Even Intel mobile processors with the same brand and sold under the same family can have different internal architectures.

But all of them understand the x86 instruction set.

How the Intel processors run the x86 instructions set has been evolving during decades, but the original instruction set still apply.

Maybe rephrasing the question would help:

Is there any point on evolving the hardware that run the 65xx instruction set at all?

[BigEd]

There are one or two very fast emulators which run 6502 code on ARM, in the PiTubeDirect project.

And I can think of at least one project mentioned here which aimed to increase the fetch bandwidth and therefore improve the number of instructions per clock. In fact maybe two.

I'm not sure whether or not we've seen a more fully pipelined implementation, other than that.

In your original post and some followups you were also talking about extending the 6502 - that makes it a much different conversation, because not only must the implementation have the extra registers and operations, but the machine code also needs to encode them. (And of course the programmer or the compiler also needs to make use of them.) (And everything needs to be well-tested and documented.)

(So you see it might make sense to start a new thread, with a new title, and a new head post which asks the question you're thinking of. You can link back to this one, and probably that would be a good idea.)

[Dr Jefyll]

tokafondo wrote:

The internal architecture of a i8086 is different from the one in a i80486, which itself is different from Pentiums, and so. Even Intel mobile processors with the same brand and sold under the same family can have different internal architectures.

But all of them understand the x86 instruction set.

Right. And a similar example is the IBM System/360, a family of mainframe computer systems delivered between 1965 and 1978. The design distinguished between architecture and implementation, allowing IBM to release various implementations at different prices.

The architecture is the defining factor. It says what's possible, and (by omission) what's not. For example, there's no ability to arbitrarily add more accumulators (as you suggested upstream, iirc).

I'm not arguing against your proposition. I'm just pointing out that the Intel i8086 doesn't seem like a good example to support it.

-- Jeff

[tokafondo]

BigEd wrote:

There are one or two very fast emulators which run 6502 code on ARM, in the PiTubeDirect project.

This could be a way to see this. ARM is a different hardware architecture. By using an emulator, that is, an intermediate layer between the binary code and the hardware, ARM can run the 65xx instruction set. It's not emulating the processor, but reading the binary file, parsing it, extracting what is 65xx instructions, what is arguments to those instructions and what is data, and then in a memory location simulating what the instructions originally tells what has to be done. Sort of following a cooking recipe.

What is the way to do that by hardware? By using a FPGA, that also simulate what the real hardware should be doing. It's not that a FPGA contains resistors, capacitors and transistors like the real CPU has, but programmable logic that behaves like the original hardware does.

So those two could be a way to implement my wrongly called HAL. Those two are ways to separate the 65xx instruction set from the hardware it runs on.

BigEd wrote:

In your original post and some followups you were also talking about extending the 6502 - that makes it a much different conversation, because not only must the implementation have the extra registers and operations, but the machine code also needs to encode them. (And of course the programmer or the compiler also needs to make use of them.) (And everything needs to be well-tested and documented.)

Of course that that would be the way to go.

Dr Jefyll wrote:

The architecture is the defining factor. It says what's possible, and (by omission) what's not. For example, there's no ability to arbitrarily add more accumulators (as you suggested upstream, iirc).

At some point in the interview with Chuck Peddle, AFAIK he says that he talked with engineers of companies about the instructions they used most and what they didn't use at all, and thought about its CPU project and the instruction set he would implement, and then, from that, designed the hardware. -- Please correct me if I'm wrong (as with any other thing as you have done - thanks)

So... at this point, about extending the 6502, I think it would be better to think about extending the 65xx instruction set and from there redesigning or enhancing the CPU hardware design itself.

Would be useful to extend the 6502 instruction set?

Would be useful to expand or extend what the CPU has to offer to the instruction set, with things like (but not limited to)... two accumulators or zero and first page implemented directly in the core die?

Would be useful to separate the 65xx logical instruction set from the hardware it runs on, like what happens in the x86, where there are several manufacturers of x86 compatible CPUs, but that works differently at hardware level?

...or is it all of that pointless because the 65xx architecture is perfect as it is?

[GARTHWILSON]

tokafondo wrote:

So... at this point, about extending the 6502, I think it would be better to think about extending the 65xx instruction set and from there redesigning or enhancing the CPU hardware design itself.

Would be useful to extend the 6502 instruction set?

That's what the 65816 does. Even in '02-emulation mode, you can do things like push literal data, push a relative address, do stack-relative addressing without using X, TXY & TYX, branch long, do long (24-bit) addressing, and more. Go into native mode, and capabilities further expand.

Quote:

Would be useful to expand or extend what the CPU has to offer to the instruction set, with things like (but not limited to)... two accumulators or zero and first page implemented directly in the core die?

You seem to have missed my earlier post (which is an easy oversight any of us can do):

• You've mentioned two accumulators a few times now. Do you have a specific use envisioned for them? I'm not sure I've ever wished to two accumulators, but I wouldn't mind having another register that duplicates the functions of X. The '816 allows 16-bit index registers (and allows a 16-bit accumulator too, independently), so at least indexing past 255 is possible there, and adds the stack-relative addressing modes. Its op-code table is full; so adding more registers and the op codes to use them would require a wider instruction word, or more operand bytes, or two-byte op codes and more complex (and probably also slower, as BigEd said) internal instruction decoding.

then I mentioned various functions you can get with self-modifying code, and later mentioned the penalties that may come with putting pages 0 and 1 on their own internal buses.

[John West]

I still don't understand what you're getting at.

The instruction set already is separate from the implementation (if we ignore the strange implementation-dependent behaviour of the undefined opcodes on the original NMOS 6502, which pretty much everyone but the demo scene does). There are many implementations of the 6502 - NMOS, CMOS, FPGA, software, discrete transistors, 74-series chips. They all execute the same base instruction set, with completely different hardware.

And of course it would be useful to extend that instruction set. It has happened several times already, with several versions of the 65C02, the 65816, and the wide variety of extensions designed by hobbyists. I have one of my own.

Quote:

Would be useful to expand or extend what the CPU has to offer to the instruction set, with things like (but not limited to)... two accumulators or zero and first page implemented directly in the core die?

Two accumulators must have already been done. But putting pages zero and one onto the chip - that is not an extension of the instruction set. It's an implementation detail. You could make one chip with internal page zero and one without, and there would be no way for software to know which it is running on. Which instructions are you imagining this change would affect, and in what way?

[tokafondo]

GARTHWILSON wrote:

I'm not sure I've ever wished to two accumulators, but I wouldn't mind having another register that duplicates the functions of X.

Ok, so we have an answer then. You say that can't see use for another accumulator, but another X like register would be useful.

John West wrote:

The instruction set already is separate from the implementation

Yes, seen like that, you are right. The instruction set and the underlying hardware is already separated, then. It seems to me, however, that not using the real thing -- a 6502 chip is considered not canon: Most of the SBC projects shown here include the 40 pin 6502 and the chips needed for it to do what intended to do. Is it like that? Do people prefer to use the real chips instead of FPGA or emulation implementations?

John West wrote:

Two accumulators must have already been done.

You are talking about 6502 emulation mode on 65816 and its A and B accumulators, aren't you? Or are there implementations of two (or more) accumulators that could be addressed with their own ADC/SDC-like instructions?

John West wrote:

But putting pages zero and one onto the chip - that is not an extension of the instruction set. It's an implementation detail. You could make one chip with internal page zero and one without, and there would be no way for software to know which it is running on. Which instructions are you imagining this change would affect, and in what way?

Yes, such proposal is not about the instruction set, but about the hardware implementation, and would fall in the category of advantages of having the software and hardware separated -- something you told me it has been already done.

Is it, then, commonly accepted that the 65xx instruction set and its hardware implementations are different things?

[GARTHWILSON]

tokafondo wrote:

It seems to me, however, that not using the real thing -- a 6502 chip is considered not canon: Most of the SBC projects shown here include the 40 pin 6502 and the chips needed for it to do what intended to do. Is it like that? Do people prefer to use the real chips instead of FPGA or emulation implementations?

I would go for the programmable-logic ones if someone would supply them ready to go; because like so many other members here, I have not yet gotten into programmable logic to any significant extent. It's on my to-do list, but there are too many other projects ahead of it. Daryl designed his 65SPI (the chip, not to be confused with 65SIB, the interface) around the 5V Atmel ATF1504, but at this point he only supplies the files and does not sell them like he did the earlier version that was based on a now-discontinued CPLD. Jeff Laughton has his KimKlone 65c02 with pointer-arithmetic-friendly extended address space and 9-cycle ITC Forth NEXT, which gives 6 new registers and 44 new instructions. Note that this is not just a proposal, but actual working hardware. See pictures in this forum post and on the next page of the forum topic. He also has lots of great ideas for making I/O super fast, some of them being shown here. It would be great to integrate these into programmable logic and offer them to everyone, pre-programmed. (But like me, he has only dabbled in programmable logic.) A few members here have made 65-family processors in programmable logic. It'd be great if all of this were available to buy, ready to go, so the user doesn't have to deal with the internals, only the application. Similarly, I have made various little boards for my own use which I offer to others on my website since I might as well order however many boards I can for the minimum price, and promote the interest. I would encourage others to do this kind of thing with programmable logic.

[BigEd]

You'll find a great variety of interests and perspectives, here. From TTL remakes to single boards with 40 pin DIPs, to FPGA reimplementations and to emulators written in high level or low level languages.

It's not helpful, I think, because it's not accurate, to seek a consensus in this situation, as to what kind of endeavour is valid, or is considered canon.

Even the terminology is not consensus: I know very well what I mean when I say simulate or emulate, but there's at least one other view which assigns different meanings to those words.

There is not a hive mind on this forum, or any other, or on any mailing list.

Better, I think, to put forward an idea and see who is in favour. There will always be some who are not in favour, because that particular idea doesn't mesh with their particular interests.

I don't know if they have already been linked in this thread, but there are at least a couple of previous topics which are worth investigating. Whether or not your ideas are new, it's worth seeing what others have thought previously, and what those ideas led to, by way of discussion or development.

A pool of odd ideas for speeding up a 6502 architecture
Index of threads for improved 6502 and derived architectures
Overview of 6502-like cores, hard, soft, partial, overblown

[tokafondo]

GARTHWILSON wrote:

I would go for the programmable-logic ones if someone would supply them ready to go.

What about the MyMENSCH SBC series? Wait. That has been already discussed here.

BigEd wrote:

Better, I think, to put forward an idea and see who is in favour. There will always be some who are not in favour, because that particular idea doesn't mesh with their particular interests.

Some ideas have been proposed just as examples in this thread, like

• several accumulators
• more index registers
• every zero page register being both a memory address and an accumulator
• every register being able to be accumulator and index register

I'm not qualified to talk in favour or against any of those proposals, and that's the spirit of this thread: a discussion where people that know the stuff they are talking about, could intervene.

Maybe hardware wise, it would not easy to implement those - or any other - proposals, but... software wise would there advantages from them? Would they make coding easier or more efficient?

[sark02]

tokafondo wrote:

I'm talking about setting a sort of standard that would allow hardware natively understand and run 65xx code as a real chip would do, but without the constraints that the 65xx hardware architecture has.

This is precisely what ARM does with their Architecture Reference Manual. It defines how an ARM processor behaves without reference to a specific implementation. It describes memory access attributes, such as whether a memory region described by the MMU is 'normal' memory (re-orderable, speculative) or 'device' (non-cacheable, non-speculative), or whether it's cache/non-cache, coherent (shareable) / non-coherent. Although it mentions the ABMA AXI bus (ARM's system bus architecture), it's just as a recommendation, not a mandate. An architecture-compliant processor can use whatever bus technology it wants to as long as the behavior of the whole meets the spec. ARM even provides pseudo-code that describes how instructions are decoded and operate, how addresses are mapped, and how interrupts and exceptions are handled.

In ARM's spec you'll not find timing diagrams, or instruction cycle counts. These are implementation details. The spec is an abstraction of a processing element. Implementation is up to you.

There's a separate spec for the interrupt architecture, detailing how compliant system should handle everything from pin-interrupts, to messages interrupts (e.g. PCIE MSIX), to interrupt routing and programming of the controller. Again, it's a behavior specification.

[RISC-V also has architecture specs, but they're not as detailed as ARM's. Same exact idea though: behavior, not implementation].

These specifications could be called a HAL. It's not how I use the term, but it doesn't entirely not fit.

More commonly, a HAL is a software layer that isolates higher level software from hardware-specific lower level software. For example, companies that build networking equipment such as switches and routers have code bases that span multiple generations of product. Over those generations the underlying switching ASICs evolve (whether they be internally developed ASICs or 3rd party), so a HAL provides a clean layer to allow one code base to operate across products.

For a CPU like the 6502, you could develop a HAL that hides the details of things like interrupt control, UART, storage, and network, RTC, and sensors, video... with applications using well-defined APIs and compliant system builders implementing the calls. That's a BIOS.

Quote:

Some ideas have been proposed just as examples in this thread, like

• several accumulators
• more index registers
• every zero page register being both a memory address and an accumulator
• every register being able to be accumulator and index register

I think these ideas start to step away from what the 6502 is, and more towards ARM, where every register is an index register and an accumulator. Same for MIPS and RISC-V.

I think at some point, where you're asking for more of this, or more of that, what you're really doing is coming to a realization that your needs no longer align with what the 6502 offers.

[BigEd]

There’s a nearby recent discussion on the 6809 with links to both the question of what the designers intended and also to what the users thought after the fact.

The point being that the 6809 was very much intended to be an improvement on the 6800.