Thoughts on Higher Level Language Design for 6502 Systems

[rudla.kudla]

Then I believe Atalan may be just the right thing for you

Errors are single most significant problem in new programming language. The number of combinations of different features is simply unlimited!

However, we do not so much talk about newbies. How many of us, who still develop something for 8-bit platforms are still newbies

I must say, I was very surprised how immature the Atalan still was, when the first game in it was developed. Had the guy who developed it bothered to ask me, I would tell him to wait

[qbradq]

...a language that reduces the entry barrier to NESdev will at least be a positive step in expanding the developer base and thus legitimizing NES homebrew.

Sorry I missed this before. That's exactly why I try to do stuff like this. I love the NES, and nothing would please me more than to see our homebrew scene expand. That's why its the Niche Instruction Code for Homebrew Enthusiasts after all

I gave serious thought to using a BASIC syntax. I have written BASIC dialect compilers before, and personally I prefer the syntax to C. Much less wrist strain However I think C is more known to the type of folks that would try to write NES homebrew. Perhaps I'm off on that.

Anyway, after I get the C-dialect version complete it would be fairly easy to implement a BASIC-dialect version that could be used interchangeably within the same source stream.

For instance, if I had a file called main.bas in BASIC syntax, and that file included a file lib/ppu.c in C syntax, the parser could switch gears for that file, then switch back. This is kinda how DOT NET languages work, but instead of an intermediate language in-memory data structures are used to keep track of scoping, types, variables, functions, etc.

Anyway, I'll keep that feature in mind. If this thing turns out to be useful I may have to implement it.

Also, I really like how the ZX Basic port was implemented: taking the assembly output of a compiler for a different platform and transforming it into equivalent assembly statements for the target platform. That's brilliant!

I can think of several languages you might be able to do that with, unfortunately they'd all be fairly inefficient on the poor 'ol 6502.

Also, I've added multiplication, division and modulus operators when both operands are constant. It helps a lot with array sizing.

[cpow]

...a language that reduces the entry barrier to NESdev will at least be a positive step in expanding the developer base and thus legitimizing NES homebrew.

Ironically, though, what language can truly replace assembly all around? Thus the entry barrier becomes:

I either:

a. buck up and learn 6502 assembly, or
b. learn some weird new language that is sorta a cross between Python, Lisp, Ruby, FORTRAN, Pascal, and some C but not the best parts of C that I'll have to somehow keep straight in my head with all the rest, *and* learn the pieces of 6502 assembly I'll eventually realize I still need.

So I've come to think that the CC65 toolchain is probably where the most accessible sweet spot is. There's libraries (KNES, others?) available for CC65 to make C work on a NES if I want to try to avoid assembly. Who *doesn't* learn C these days?

I gave up trying to write my own assembler not because I realized it was too hard, but because I realized I was only adding to the mass hysteria. Just off the top of my head: ASM6, CA65, QASM, NESASM3, P65, ... there's probably more. I can't keep track of how many threads start:

"So I picked up a tutorial and NESASM and I have a problem..."
"WTF are you using NESASM for? Use..."

So I guess where I'm going with this is that's why I started working on NESICIDE in the first place...to reduce my entry barrier into NESdev. I know it sounds ridiculous, but that's my way of learning...but in doing so I hoped to build something that would, in turn, reduce the entry barrier for others.

One of the goals of NESICIDE has always been to be rich with tutorials. It's not there yet, but it's already a fairly decent integrated environment in my opinion. Tepples, your russian_roulette makes a pretty darn good "I just want to throw some text up on the screen and move a sprite around" sort of intro package. I am hoping to use it as a basis to generate many many other tutorials.

I know I know...we all have our favorite development environments and none of them honestly actually include anything with the word "Integrated". Perhaps what I'm doing is ultimately a waste of time...but I don't think more languages is the answer!

[tepples]

Tepples, your russian_roulette makes a pretty darn good "I just want to throw some text up on the screen and move a sprite around" sort of intro package.

Thank you. It's a bit lacking in the "move a sprite around" department, but I'm about to fix that in a few minutes.

[qbradq]

The problem I have with Assembly is that it drastically increases the development time, which raises the barrier to entry. The problem I have with C (on this platform anyway) is that it is very easy to paint yourself into a corner performance-wise. I am trying to create a happy middle ground.

I had not thought of the proliferation of languages as a barrier to entry. That's a very good point. Something that's "not quite C" could be more confusing than a language with it's own syntax. Good food for thought, especially considering...

I am going to have to re-write the parser. This is the first time I have tried to implement a language with user-defined types and arrays of user-defined types, and I had some learnin's to do

[3gengames]

Truthfully, I don't have a problem with assembly the more I do it. I keep saving subroutines I need and I take them from other programs, I can start a good game engine to anything within an hour or two just by copying all the code I've used before, and then just adding the functionality I need from there. You just have to work with it, learn it, and create the libraries/subroutines you need and that takes a while, but after some time it becomes a walk in the park.

[qbradq]

It is true that over time you get better at assembly. I certainly have. However the advantage of a high-level language is not that you don't have to learn assembly, it's that you can express things much more clearly with less code.

For example, the last project I worked on I needed to calculate a pointer into a map data table. In C it would look like this:

Code: Select all

byte *curTile = &mapData + (yPosition << 5) + (xPosition & 0x1f);

In assembly that took me about 50 lines of code and two attempts before I got it right.

High level languages do not reduce the complexity of the logic, only the complexity of the syntax. Equivalent C code is much easier and faster to write, read and maintain.

[Shiru]

Equivalent code in C or other HLL is few times shorter than hand-written in assembly, and few times easier to read and maintain. Less source code - less work. If you have enough CPU resources to be able to use slower code, it is a really good exchange. No one say you thanks if you waste few week or a month writing functionally equal code in assembly and will have 50% of CPU power not used for anything. So no doubts HLL are useful.

[3gengames]

Is there any C generated code that's faster than a hand written program? I've never seen an example, and doubt it exists myself. The computer can't see into the future and tell what you're going to add/plan to/want to, and I doubt it can make those optimization's I can just thinking about it.

[cpow]

The problem I have with Assembly is that it drastically increases the development time, which raises the barrier to entry.

I disagree. Using assembly is probably the lowest barrier. Just look at the expertise available on this board regarding assembly tips, tricks, and analyses of assembly-gone-wrong.

Using C is probably the next-highest barrier. If someone posts a question about C in this forum, the assembly gods herein will either know C and be able to help directly, or will try to help by compiling the code and reading the assembly. In my work the most common question I ask when someone has C code that isn't doing what they expect is "did you look at the assembly the compiler generated for you?" If not, or if they cringe at me as if I just asked them to eat their veggies, I suggest they send me their source and I'll take a look at the assembled output if I can't figure out what's wrong immediately at the C level.

Using something other than C/assembly is the highest barrier...

If I write something in <choose-your-favorite-high-level-language-that-isn't-C> and am having troubles, the "barrier to help" is higher unless the language I've chosen happens to also have behind it a community of experts, or is widely available enough that anyone can quickly figure out how to compile it to assembly to be helpful at that level. But then the response to your question is, if you're lucky, of the form:

"Well, I don't know <language> at all, but I can see why you're having problems because the assembly generated by its compiler contains a <anomaly> which doesn't make any sense. I can't help you figure out why because I don't know <language>."

With something like C you don't have to rely on the original author of the language being around to be able to answer syntax/semantic questions regarding its use. You don't [usually] have to rely on the original author of the compiler being around to be able to answer questions regarding its seemingly errant translation of a chunk of code. This is perhaps not the case with CC65 because it is still in development, its author is still around. But with GCC I often am heard laughing uproariously whenever I hear someone saying "it must have been the compiler...I didn't make a mistake in my code."

[tepples]

Is there any C generated code that's faster than a hand written program?

As I touched on before, that depends on the skill of the hand writer of the program, and modern compilers for 32-bit and bigger architectures routinely beat all but the most skilled (and highest-paid) assembly experts. The consensus from what I have read on the Internet is that on 32-bit and bigger architectures, there is more return on investment in hiring somebody to optimize the algorithms or in buying a fancy compiler than in hiring somebody to take the existing algorithm and try to write an improvement on what GCC or Clang produces with options like GCC's -S -fverbose-asm. See: Superoptimization on Wikipedia; top answers to this question on Stack Overflow.

And of course, a program written in assembly language for one architecture and then emulated on another architecture is going to run slowly. With assembly, you limit your audience to one architecture unless you know that the vast majority of your audience will have a machine dramatically faster than the machine you target, which is the case when targeting NES.

[Shiru]

Is there any C generated code that's faster than a hand written program?

Not on 6502 for sure, but you can easily found that hand written assembly code is not faster than (much larger and ineffective) compiler-generated on some architectures with slow RAM and algoritms that heavily use RAM, like data processing. For example, ARM-based Pocket PCs and mobile phones. That's because memory speed is the limiting factor.

[tepples]

Shiru: In those cases, it might be true that the programmer forgot to tell the compiler's scheduler how slow the memory is, and the compiler just assumed zero wait state.

Another interesting article on whether hand-coded assembly beats compilers: Great Debate I

[zzo38]

Certainly hand-coded programs can be far more efficient (if you are good at it). I have made some suggestions for LLVM which could improve the optimizations (I have many suggestions), as far as I know none of them are implemented yet. There is also the story of Mel, who did strange things that no compiler does, such as use no timing loops but instead set up everything so that the timing of the computer is exactly how the program wants it, and other things. The real advantage to compilers, though, is portability (although this does not apply to the NES, obviously).

[qbradq]

Assembly is the lowest barrier to entry? I disagree. NES development took me way longer to become proficient with in assembly than did DS and PSP development in C, and XNA development in C#. All of these platforms are as complex than the NES, yet I was already familiar with the languages, which reduced my learning curve.

Granted a new language will not benefit from prior knowledge, however it should be easier to learn for someone already familiar with a similar language (such as C).

Also, the comment about most people learning C these days is way off. 90% of the programmers I have at work have no C experience, and usually end up with a segfault in the program they have been asked to modify.