No runtime
No BCL
No objects or GC
No debugger
Strings are ASCII
I did not see the readme mention anything about bool/byte/char/short/int/long sizes or signed and unsigned. It can be quite a surprise to find yourself with 8 bit long longs! As some found with sdcc for gameboy.
The NES has 2K ram, where you can get carts with mappers that allow you to use prg as ram as well though, this is still limited. Also, the "stack" as it exists must fit on a page (256 bytes). Putting a runtime or sorts onto an NES itself is a big feat given this and requires a lot of manual twiddling.
The hardware stack pointer is restricted to indexing within [$0100, $01ff] but, lacking a stack-pointer-relative addressing mode, it is more preferable to realize a parameter stack using a zero-page pointer indexed with the (zp),Y addressing mode, as cc65 does.
This looks very much like "Hello World" in C, taking advantage of the latest C# features in 2023.
If you admit that it looks like C(99), what's "C#" about it then? This can probably be done with just about every C-syntax-derived language, which is why I think the title is a bit clickbaity; I was expecting some sort of highly-stripped-down CLR.
So strange. Someone invented a computer language called C and is not proper C until it is stabdardised by a committee. I would say the original C is proper C. Got a whole operating system to run with it.
Organisation is nothing if we do not accept individual’s role.
Not the subset you can fit onto a 6502, thus that subset fits the same purpose as K&R C, a portable macro assembler, calling into functions that are written in raw Assembly, compiled by an external macro Assembler.
And good luck making good use of 6502 registers for C code.
When I saw it only seems to support a 'main' I got disappointed.
If it could even get to 'method calls with ref structs' you would start getting into where I'd want to YOLO with it, maybe even use Nesticle to test for the irony.
>For lack of a better word, .NES is a "transpiler" that takes MSIL and transforms it directly into a working 6502 microprocessor binary that can run in your favorite NES emulator.
>Building a project should produce a *.nes binary, that is byte-for-byte identical to a program written in C.
What about memory management? Is the garbage collector included in the generated code? If not, any idea on how memory management is done?
No objects and GC so far. I guess local variables are stored on the stack and for everything on the heap (globals, strings) the transpiler maps MSIL loads and stores to 6502 loads and stores.
Saw this make the runs on twitter a few weeks ago and was confused, I had assumed they had ported a limited run time by making a custom cart with a large prg rom, which seems like an amazing feat actually...whereas this is a 6502 compiler essentially with some limited functionality.
No shade btw, just seeing the title made me perhaps expect quite the effort while this is still a fun project of sorts.
I wonder how's the performance vs. C (for both, C# and Rust).
Edit: It's my understanding that the 6502 is extremely stack-limited, so a well-versed assembler would use the stack very little and allocate mostly on the heap. In C, you can replicate this with global variables, and I believe (and I would be very happy if someone related to the 6502 rust port could chime in here) on Rust you can do the same with `static mut` on Rust 2021 and `Unsafecell` on Rust 2024.
