It’s not the same. C is a low level language that can deal directly with memory and doesn’t need to rely on any apis. Contrary to that GDScript can’t touch memory and the only way to accomplish anything is via api calls that are supplied by megabytes of engine code.
GDScript couldn’t do anything on an 8 bit platform. It’s completely unsuitable.
Yes, but a library for Assembly wouldnt need to touch the memory if it supports the basic hardware functions.
the C method literally uses C in the low level environment because it is low level, but still higher than assembly, nevertheless; I am not saying subsitute GDScript with Assembly, i am saying you would still require an asm file, headers, etc. etc. etc., but it would be done for you via plugin utilities. You wouldnt have to touch the assembly despite it still being used.
Just a disclaimer, REQUIRES EMULATOR FOR TESTING or something like that
The thing is, you need to touch a lot of assembly (or low level C) if you want to write performance critical code for an 8 bit machine. A language like GDScript is simply too far up to do the job in a required way.
Try to code a game for NES to see what exactly is involved.
Basically, using nothing of Godot but GDScript and the editor as an IDE with a plug in for each platform that would include all the tool chains necessary, including compiler, assembler and linker, asset packers, etc.
Right ?
Yes, but if you literally just use a compiler like you normally would for coding NES, and use an emulator or a DSP cart to run the games, then this isnt an issue.
And a tile map. You forgot the tile map 
What compiler?
Precisely—
Literally exactly this.
Any random compiler per platform, i have worked with SNES programming a tiny bit, you usually use a terminal-based ROM compiler in order to test your code. And if it doesnt work, you recompile, and again and again, it really sucks ngl. Which is why a plugin in godot would be good.
*blows on old SFC cartridge for no reason
We’ve already been there. And you ignored my question: How does var foo: float = 0.5 compile to 6502 assembly?
i have literally never worked with 6502 assembly ( i am assuming this is for the NES), i have only messed with 65c816 assembly, which is for the SNES,
I already answered that question multiple times through various explainings of the same concepts,
you dont truly compile the GDScript, you simply translate it with a simple function to do such, writes it to a .asm doc file, and then you compile to whatever rom, e.g. FC, SFC,
etc.
its not as complicated as it seems, really.
*And the tilemap-to-bitmap, etc. could co-exist.
You do understand that a basic GDScript line like var foo: float = 0.5 would compile into amount of 8 bit assembly code that eats up half of the NES’ memory.
You can’t just “compile” GDScript into assembly. It’s too high level. You’d need to downgrade it significantly to make it almost like assembly, or at least C, in which case it’d completely stop being GDScript.
Go and make it happen then! 
^
|
Compilation only neccessary when it needs to be converted to a ROM.
*Whenever i have enough time, i would love to, but that isnt gonna happen for at least a few years, sadly.
Excuses, excuses…
For an analogy, i will use Japanese text,
What is Desu in Japanese?
English doesnt have a polite sentence ender so its impossible to translate,? Wrong;
you take the nearest equivalent for that language. Its equivilant is something like “Is” in English, but still not exactly the same? Yes.
same thing in Assembly and GDScript, You dont need to literally convert all the bytes of memory in a single simple var sentence in GDScript to make a game for a console that cant handle modern memory.
Sure.
Or like Godot, only 8-bit.
Have you ever heard of a library before?
A simple function that takes the literal TEXT of a gdscript and makes the bare-bones equivilent in assembly wouldnt need to worry about data restrictions.
If i thought i could port my Godot game to the SNES, i would be out of my mind;
hence, entirely different from what i am saying.
You can port it. You just can’t ex-port it.
Which is what i am saying. Port it as in i cant simply run it on my 16bit console.
The only issue for my idea is that someone would have to study the NES, SNES, Genesis, Atari, or any other consoles to be supported, their hardware and everything from every aspect and become a master, and make a simple json document to assign each gdscript function (or just made up functions in the library) to a text value to replace with on a asm file.
Other than that this would be very easy.
So the roadmap would go as follows:
Sounds doable when we put it this way.