I tried this with cc65. OK, that's a 6502 compiler and not an '816, however... It couldn't compile itself - too large. And even if it could - the binary for x86_64 is half a MB, I imagine the code density is worse on the '816 so getting change out of 1MB may be a challenge... But RAM is cheap as is storage these days.

I fear that a native C compiler would be a little reduced - like TinyC, SmallC, etc. but it may be worthwhile looking... One day!




That's essentially what RubyOS is - although the CLI is written in BCPL - it could be C and I do have a C version of my nano-like editor that runs on the board in 6502 mode - 1500 lines of C compiles to just over 15KB of 6502 code.

-Gordon

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

Most modern compilers these days try to do all passes in one large go; which was not possible in the days of less memory. You'd likely be better off designing a compiler that has multiple stages that can pick up where the last one left off.



Comparing an x86_64 binary size to that of a 6502 or 65816 isn't a very fair comparison. A single pointer on x64 is 4 times as big after all; let alone some of the crazy instructions they've added to the x86 platform over the years. (I was looking through it, they have an instructions specifically for doing AES cyphers now...... >_< )



Maybe, maybe not? It really would depend on which revision of C you go with, and how you structured the code. The first publicly released MS compiler fit on 3x 360Kbyte floppies, and you can see how MS split the executable up into smaller chunks to make it fit in the available RAM of the time of the 80286.

This version was compatible with K&R C, but I don't think you'd be hard pressed to get C89 into about the same memory footprint.

Most of the revisions to C add a few basic QOL stuff to the language (C++ style end of line comments and wide character types for example), after that the larger part of the changes are to some of the standard libraries and predefined macros. Nothing terribly complex, though I am just skimming over some of the changes for each revision as I type this.

Trying to get all that working on a 6502 might be a trick with the 64KB address limit. The 65816 should be able to do it provided it has about the same range of memory you'd typically find on a 286 of the time.

Maybe you could do with even less with using disk space for scratch/swap space?

That being said, TinyC, SmallC and lcc are mostly monolithic designs, intended to be run on systems with copious amounts of RAM available to them. You'd want to split up the stage1 and stage2 passes in those compilers to get them to fit.

As for the standard headers that starts getting into the realm of Posix. If you're designing something like an OS you can pretty much forget that these even exist; you end up having to implement your own versions for your kernel, and even then most Un*x like OSes only implement what they absolutely need in their kernel and little else. Usually this is split into a special libk which is a subset of libc so it's smaller and can be statically linked into the kernel.

For me and the toy OS that I've been working on I've generally found that I just need just a very small subset of what these libraries offer to get anything functional. The most elaborate thing I have in my code is my own hacked version printf() largely based on the one in FreeBSD. After that I mostly just need some of the string functions such as memcpy() and friends.

Things like the stdio FILE are nice to have, but aren't something strictly required for a functional C program. It's really only useful when you want to port the code from one OS to another and you want to avoid using platform specific functions. If you're writing a compiler specifically for the 65xx that you intend to run on that CPU then you can work around this with some wrapper/stub functions. One version that calls the FILE version for all other OSes, and another that just jumps to ROM or whatever function table for your 65xx OS/monitor/whatever.

I said BCPL seemed like a bad choice. I also said that I didn't know anything about BCPL (Wikipedia is not worth much). I'm not opposed to BCPL.

The whole point of having a processor with support built-in for emulating a byte-code VM is diversity. I want people to develop multiple byte-code VM systems. This is an opportunity to be creative! Design a byte-code VM and write a compile, all of your own. Or, go retro and emulate some existing system (what you seem to be doing with CINTCODE).

I was only interested in the W65c816 as a way to get C running on the processor. I could write my Forth for a W65c816 that has been updated with a few instructions to support Forth, but it is still not that good of a Forth target, so I'm better off sticking with my own byte-code VM that is designed specifically for Forth. I mostly just want to get C running because the majority of people demand C.

Somebody (it may have been you) asked what the point would be of emulating the W65c816 when it is still possible to buy W65c816 chips and boards. There are reasons:

• Speed. A W65c816 chip runs at maybe 12 Mhz.. If my processor is running at 100 Mhz. it should be able to emulate the W65c816 at the speed of a 20 Mhz. W65c816 chip. This is just conjecture because I'm not there yet, but it seems reasonable. Several of the W65c816 direct-pages will be mapped to the FPGA's internal memory for speed.
• Versatility. An FPGA can be reconfigured for a variety of I/O for a variety of applications. WDC is not this flexible. I'm hoping to get audio and video comparable to the Commodore-64's SID and VIC-II chips. That would be awesome! I'm also aiming for the least-expensive FPGA chip available. Getting both awesomeness and low-cost might be a lot to ask for, but that is the idea.

Okay, here you are talking about the versatility issue that I mentioned above.


I'm working on my assembler/simulator for my processor. I've done this before on the 65c02 on the Apple-II (actually the Laser-128 clone). It did source-level debugging on the MS-DOS via an RS232 cable. I used this to write my symbolic math program (it could do derivatives, but I never got as far as doing integrals). My Forth was derived from ISYS Forth but I had a cross-compiler running under MS-DOS. I doubt that there was any C development system that would have been capable of a program like this.


A big part of why I want to support a byte-code VM is that this will be in external memory, so your 1/2 MB requirement would be realistic. Internal memory is faster, but it is also very limited in size.


I don't think that I'm naive about the concept of a byte.
It is just that, designing this thing, I found that it is much easier to make it efficient with the limitations I described.

I could make it work with packed W65c816 code, or your CINTCODE that is also apparently packed. To do this I would need something similar to the prefetch queue of the i8086. This would provide me with a queue of bytes that have now been unpacked with one byte per word. This is possible. This would require some more support from the FPGA to fill the prefetch-queue and unpack the bytes in the background. It might be worthwhile, but I don't need that for my own byte-code VM design.

As for a SWITCH statement, I already have support for a 256-vector jump-table. That is how the byte-code VM works. I currently only support one jump-table though, so I don't have support for a SWITCH statement. If there is any call for a SWITCH statement, I could provide this. Keep in mind though that a 256-vector jump-table consumes 1/4 KW of internal memory, and there isn't a lot available.

What I already have should support a jump-table in external memory for a SWITCH statement. This might be fast enough. What do you need a SWITCH statement for? All of these design decisions are trade-offs. My plan is to start with a simple system and, if certain applications need features that I don't have, I will provide those features if this can be reasonably done. I don't want to predict ahead of time what features are possibly needed and try to provide them all.


Nobody writes large amounts of assembly code any more. For one thing, my FPGA will only provide 6KW of code-memory and 2KW of data-memory. How large of a program can you write in this limited space?

People write large programs in high-level languages. That is the purpose of supporting a byte-code VM! They can be joyful enough doing this, and they can have a MB of memory to be joyful in.

Somebody smart will have to write the byte-code VM primitives in assembly-language, and will have to write the ISRs in assembly-language. Apparently a super-duper assembly-language expert such as yourself would distain of such low-level programming because it is just not joyful enough. I'm doing this right now for my own byte-code VM design. Drogon may do it for his CINTCODE. I've written much more low-level assembly-language in the past. I figured it out. For me there is joy enough in accomplishment.

I read about the MC68000 but it didn't seem interesting.

In Forth it is common to keep the top element of the data-stack (the TOS in Forth terminology) in a register. On the i8086 this register was typically BX.

The MC68000 has a distinction between registers used for data and registers used for pointers. So, should a D-register or an A-register be used as the TOS? The TOS is a pointer for instructions such as @ and ! but is data for instructions such as + etc.. I thought that the i8086 was a better design for Forth.
I also thought that, if your data was 16-bit, there was no advantage in having 32-bit registers --- but, 32-bit data read or write obviously takes twice as much time as 16-bit data read or write given a 16-bit data-bus. The i8086 breaks out of the 64KB limit of the Z80, but it does so with 16-bit registers, which seemed clever to me.

Actually, you may not tell me that I have a 1970s mindset. That is just a put-down.

You are saying that I'm just a stupid little student who has never written an assembly-language program, but goes on internet forums quoting from textbooks and pretending to be a programmer. That is a gross put-down.

You are telling me that I hadn't considered that a very short interrupt-to-first instruction latency doesn't help if the instruction set is so weak it takes 10x the instructions to do the work that needs to be done. Who would have thunk???

I didn't say that the 6502 was the peak of computing greatness and all advances since then have been solving the wrong problems. You are painting a picture of me as an utter fool.

You are saying that the only point of the project is to emulate the W65c816, although I clearly said that the point was to support multiple byte-code VMs --- my own that is mostly for Forth, possibly the W65c816 that would be for C, possibly CINTCODE that would be for BPCL --- people can exercise their creativity in writing a custom byte-code VM or providing support for an existing byte-code VM.

You are telling me that my project is "absurdly pointless." That is a gross put-down.
I think that I have had enough of your put-downs. So, goodbye to you! I won't respond to you again.

Also, I have had enough of RISC-V enthusiasts telling me that I'm stupid to try doing anything of my own design, because it will just be pointless to everybody except myself. The RISC-V enthusiasts tell me that I should be smart like them and jump on the RISC-V bandwagon --- doing so will give me an instant 20-point I.Q. boost, getting me into the three-digit range finally.
The RISC-V enthusiasts believe that they have solved the problem of how to design a processor. They believe that any alternative effort can be proven to be absurdly pointless without being examined. Such certainty must make people feel good about themselves! I refer to this as the "conquistador mentality."

[/quote]

That's a good point. The C compiler from UNIX V7 in 1979 was still hosted on and targeting the PDP-11, and it had separate executables for each pass/phase. The overall cc compiler ran cpp for the preprocessor, c0 for the first pass (parsing), c1 for code generation, and c2 for optimization. One or more temporary files were used to store the output of each pass for use by the next pass.

If somebody wanted to port a C compiler for self-hosting on the 6502, I suspect the basic concept from the 1979 compiler would be a good idea. The PDP-11's memory per-process wasn't too far off from that of the 6502.

Personally, I'm looking at porting chibicc for the '816 as a cross-compiler, initially, and then to self-host.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

In my reading of the thread, it was sark02 who first raised the temperature.

Ideally, of course, it doesn't matter how things started - we should all be trying to de-escalate.

But it's clear enough from my own posting difficulty how difficult it can be.

Oh Ed, try to not be such a killjoy, eh?

Feel free to leave this thread if you object to the sport.

Or indeed if you don’t want a productive technical discussion.