I'm talking about making the 65xx instruction set a logical, not hardware tied layer of programming, and then have something below it that would make the code run on whatever selected CPU or MCU.

There are all those implementations that run on operating systems as simulators or emulators. But that's not what I mean.

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.

That way, a programmer wouldn't be taking care of the size and location of the stack, the zero page, the width of the bus or how much memory the system can handle: all of that would be handled by the hardware below the HAL.

Also, the programmer would be able to use as many registers would be needed, and with no limits of width. The HAL wouldn't, again, be taking care of that.

What do you think?

Not sure quite what your distinction is. Do you mean something to run on top of some micro, like 68k or ARM, or do you mean running on bespoke hardware like gigatron?

What is it that's being abstracted, I wonder - if I have some stack of hardware and software which can do INX, LDA, PHP, the next thing I will want is a means of doing character I/O at least - and perhaps more, perhaps audio, video, serial or parallel devices. So what shape do you have in mind for the abstracted hardware machine?

I commonly use lib6502 wrapped in run6502 to run 6502 code from my command line - I'd call that an emulator, although it's not an emulator like VICE or MAME, with an emphasis on screen and keypresses and even joysticks. Similarly py65 is a relatively bare 6502 emulator for the command line.

Think of it as being a sort of high level language. At first, the programmer would declare registers as needed, and from there things like memory sizes, bank boundaries and things like that would be forgotten.

The underlying hardware would take cate of that.

Currently, all 65xx emulators are limited by what the 65xx chips can do. But that"s a.limitation of the chips themselves, not the instruction set.

This way, the programmer could have LDA, LDB, LDC, LDD... instead of LDA, LDX and LDY only.

I believe there's at least one emulator out there which accepts a machine description (perhaps in XML) and then allows a program for that machine to be run.

I don't quite see clear distinctions in your idea, as yet, between
- the programmer's model of the CPU in question, which is some sort of super-6502
- the assembly-level mnemonics a programmer might use
- the format of the machine code, or bytestream, which is ultimately run

When we bring up a new CPU, whether it be a 6502 emulation, or a derivative, or something unrelated, we find we need
- an instruction set architecture
- which includes a programmer's model
- and the instruction encoding including widths and lengths of instructions and bitfields within
- an emulator so we can run code, possibly including a disassembler and debugger
- an assembler so we can write code
- and documentation so other people can join in

and if we're planning on a hardware implementation
- and a microarchitecture, if we're implementing in hardware
- a simulation of the implementation, if there is to be one
- a monitor or at least program loader

You'll note that Java is a high-level language, which is compiled to a bytestream, which encodes the instructions to be run on a virtual machine, the JVM. The JVM could be implemented as an interpreter, could use JIT technology, could even be implemented directly in hardware. There is a great deal of documentation to accompany the whole endeavour.

HAL -> Hardware Abstraction Layer?

Struggling to think exactly what you want... In terms of high level languages - well there is Java (mentioned by Ed) also the USCD P-System that runs on a variety of platforms but it's not "hardware speed" as such. Same for BCPL - where there are 16 and 32-bit variants that compile to a bytecode than can then run on various 8-bit micros including 6502, 65816. In both cases you have a system that's more or less cpu agnostic.

But some sort of "super" 65xx that works out what zero page you need, what stack you need to take the burden off you, the programmer? I am thinking that's really what high level languages are for. But maybe you can emulate something using a macro assembler combined with some sort of code post-processor? I'm finding it tricky to not just simply say; Use a high level language...

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

The more I think about this, the more I think the term we're looking for is Virtual Machine. It's a VM, not a HAL, which gives you a new fictitious instruction set for your programs to use.

It's then necessary of course to have an assembler, a compiler, or an interpreter, to be able to write programs in a practical fashion. Or to have any combination of the three, naturally.

And yes, both Pascal and BCPL have prior art for us to learn from. Sweet16 is somewhere nearby too. As well as perhaps the Z-machine used for adventures. And maybe others: PICO-8 perhaps, and uxn.

I've seen many times people complaining about the limits of the 65xx CPU.

Of course that seasoned programmers have managed to squeeze out every bit of power the chips offer, and have created workarounds for things the chips are short of.

You can do things with A that you can't with X and Y. At least, directly. But then you have the Txx instructions that are a native workaround for that.

And that's just an example.

But... what is the reason behing that limits? The hardware cost. If they wanted a low cost chip, they had to put the minimum needed in the physical core and then work from there. For the things the chip was intended to do ("replace logic" -- Chuck Peddle) it was more than enough. And the way they made the inside electronics support the instruction set logic behaviour, it was way more than "more than enough".

BUT the 65xx instruction set and the 65xx logic architecture could be enhanced, too.

What about having not one but two accumulators, A and B? or better why not having eight accumulators? or even better: why not having a set of registers that could behave all of them equally? Every register IS an accumulator, and also can do ANY of the things the other existing X and Y registers can do.

What about having the zero and one pages directly in the core of the CPU? They would be physically tied in a way that no system bus would be necessary to be used to access its memory locations. You could even access its values down to the bit.

If all that expansions would be implemented, then the instruction set should be done too.

So for every register there would be instructions that would do the same things they currently do. LDA, LDB, LDC, LDD... or INA, INB, INC, IND... you name them.

Some of those instructions would maybe loose their purpose like the Txx ones. Maybe they should be there just for compatibility reasons.


So if you get the idea and keep with me until here, let me thank you for reading and continue.


Would this mean that a new Super 6502/816 CPU should be designed to accomodate all that changes? Not at all.

What could be done is make the instruction set a logical layer on top of a hardware layer, and create a HAL between them.

I'm sure that many programmers here, even professional ones, have came up more that one time with the thought of this routine would be far easy to code if instead a single accumulator the chip would have two or something like that -- but the chip doesn't have two but one.

Following with the example, the programmer would create its application using what he would need to, with the 65xx instruction set as a logic resource.

And once finished and with the help of a compiler, creating a 65xx core with the logic supporting its application, that could be transferred to a FPGA device.

Maybe that 65xx core would have two ALU. Maybe four. Or four accumulators. Maybe for the purpose of the app, just with zero and one pages and ROM included in the FPGA would be enough.

In the beginning there were a lot of 65xx M/CPU variants that had features restricted or removed because there was no need of them. But this would be the reverse. The programmer adds features as needed.

That's the concept I'm talking about. Making the hardware follow the instruction set and not the opposite, like it's now.

And fear not of losing compatibility: the programmer could always use the standard 65xx way of doing things and have FPGA recreations of every 65xx CPU as needed.

OK, by introducing the idea of creating an actual CPU on FPGA, for the purpose of running an application, you've gone into a different direction from where I thought you were - in your head post here you said "make the code run on whatever selected CPU or MCU".

But you're almost moving in the opposite direction of what we usually mean when we speak of abstraction layers - you seem now to want the programmer to write their application and also describe the CPU it should run on. Or perhaps it's your compiler which invents the CPU? What do you know about clang and the LLVM? About how compilers work?

I'm also wary of the starting observation that the 6502 is difficult to program - is that an observation coming from great experience?

I'm sort of reminded of the Transmeta Crusoe here... not sure it might be applicable, but I don't think it lived up to all expectations...

-G

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

The compiler would make a pass and detect instructions used sort of...

and so on, so the final VHDL would have what the code would need to run



It's not about being difficult to program, but about expanding what the hardware limitations imposed in the day.



The problem of the Transmeta Crusoe was they were targeting the x86 world, dominated by then by the Mhz war. People were not concerned about power efficiency at all. Maybe in the industrial MCU world, or the mobility world they could have stand a chance, but it just didn't happened. They are buried next to Cyrix and companies like that, they say.

In the world of CPU design, the complexity of the microarchitecture is always a tradeoff against the maximum clock speed. That's worth bearing in mind - the more resources you add to your CPU, in general, the slower you'll need to run it.

A second tradeoff that's usually present is that the density of the machine code is also a function of the complexity of the microarchitecture. A more complex machine needs more bytes of code to tell it what to do, and that affects the memory bandwidth available for the application, or affects the size and therefore the cost of an instruction cache.

But another way to look at this is this: if you find an idea interesting, by all means pursue it. Show your progress, show your prototypes. Have fun. If people join in, so much the better - but they usually don't, and if your starting point is to make a team and a consensus before you have a prototype, you will I think have an uphill battle.

Show us what you mean by building it!

Well... thanks all for your comments.

It seems to me that the 65xx ecosystem is strongly influenced by the hardware it runs on.

"All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection." -- David John Wheeler

Nicely put. Ed. Indeed, even developing an actual specification for a prototype would be a battle. It'd be educational, though...

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

You're probably right there... I can't think of any (65xx) systems by different manufacturers that might in any way be considered compatible. Even in the same manufacturer... Apple // and Apple /// ? Acorn Atom, BBC Micro? Different makers had different ideas and even in the same company ideas differed (Sinclair ZX80, 81 and Spectrum) - the only common thing is that you need a little bit of ROM at the top (or a way to get code/vectors there) and a little bit of RAM at the bottom.

Even BASIC (moving to a high level language) wasn't that universal - even between systems which had a MS derived BASIC - "what are the peeks and pokes" was what we often asked when we got our hands on something new... (OSI, PET, Apple, Vic20, C64, ....)

But things like the USCD-P system did run on many different platforms and CPUs but we're back to an underlying VM or some sorts. I'm most familiar with it running on the Apple II (so 6502), but did briefly work in a lab where it was also running on some weird Z80 system (it may even have been a CP/M system) and a Terak (LSI-11) system. Programs could run over many different systems - almost - My application used graphics on the Apple II so that more or less confined it to that platform.

I do like the idea of analysing code then synthesizing an FPGA to run just the instructions that code actually needs - so you have a plethora of instructions, a high level language (or some macro/meta thing that's like a very posh macro assembler?) then using todays compiler technology
you optimise it out, generate the instructions you actually need use that to generate a custom CPU and 'ROM' image, program it into an FPGA and off you go... But that almost has echoes of the Fairchild Symbol Computer...

See: https://muse.jhu.edu/article/235250

... and when looking for that, my initial search brought this up:

https://dl.acm.org/doi/pdf/10.1145/53990.54000

which might be worth a read.

However I'm suspecting that this starts to get away from the 65xx world, even if you create your instruction set to be very 65xx like...

-G

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/