I must say I disagree with this one. Assembly has a lot of problems (if it didn't, high level language would never have been invented !), however, I don't think it is unreadable at all. Of course if you do comments like that :The problem with pure ASM is that no matter how much you comment it, if you leave and come back a few months later, the code will be almost unreadable. Much like commentless Perl, and very much not like well-written C++.
Code: Select all
ldx #$02 ; Load $02 into x
As for people who says assembly is not a problem, again I disagree. It has the following inconvenients :
- Slow developpement time, you have to write a lot of instructions to do something conceptually simple
- You have to loose a lot of time deciding which register will hold what, and think again if somehow the program is better by changing this choice at a later time
- 65xxx requires a lot of Temp variables (usually you'll need at least ~6 of them), and those are a nightmare. It's so easy to have them overwritten in a subroutine call, and this is extremely tedious to debug. I try to always comment which Temp variables I use, but this is not always up to date
- Very error prone, I have almost never developped a function that worked as expected on the 1st try. This is true with computer science in general, but in assembly it's much more than with high level language
- Although the CISC design of 6502 makes it relatively easy to write proper code, when you suddently run out of registers because you'd like to have that Z 3rd index registers, things will go really harsh as this means a lot of saving/loading to zeropage temp variables, loosing a lot of developpement time for something that is not conceptually complex
- Not portable : If you want to port your project to another platform, you are forced into an entiere rewrite. Also it's much easier to convert from one HLL to another HLL than from one assembly to another assembly. Even changing the assembler itself for the same platform (e.g. switching from WLA-DX to CA65) can be almost impossible without a complete rewrite !
I agree. This casting to int is the #1 problem : In 6502's case that'd force the int size to 8, but it has to be mimumum 16. Therefore for the code :Bigger problems come from C always casting to int when a type is shorter, lack of rotate operations (compilers have to guess when those are usable), etc.
Code: Select all
char a = whathever();
char b = whathever2();
char c = a+b;
Another problem is the assumption that all variables are on the stack. In theory it's easy to draw a function graph and to eliminate this problem, but the interupts and the existance of function pointers makes this completely impossible. I think SDCC somehow managed to fix this problem, unfortunately this compiler is much too complex for me to understand anything about it's inner working.
The combination of those 2 problems (16-bit default and variable stacking) makes it impossible for ANSI C to be ever efficient for the 65xxx. (pehaps for the 65816 it gets a little better, though). It could be possible for non-ANSI C to work, but then we'd as well invent another language.
Now there is some other HLL solutions worth mentionning :
- ATALAN programming language - designed specifically for being efficient for 65xx. I have no idea how good it is, but looking like an interesting HLL solution
- Virtual machines.
Since with compiled HLLs your execution time is going to be bloated anyways, VMs does that but at least they keep the code size small. So if your execution time will be bloated, at least your ROM size won't, unlike what CC65 produces. You could even have a smaller ROM than what pure assembly would have lead to ! On 6502.org I've heard about- Forth (they seem to be very fond of it)
- PLASMA
- AcheronVM