Has 'C' replaced assembler as the programmers preferred language of choice

[kenames99]

C is for portable code while assembler is very machine specific. even assembler code for an Atari 800XL wont run on a Commodore computer even tho they have the same cpu.

[Wally1]

c64 has 6510 cpu. 800xl has 6502

[Bryan]

c64 has 6510 cpu. 800xl has 6502

The point is they contain the same CPU core and run the same code (until the code accesses something specific to the system). The 6510 has some built-in IO which saves the cost of a couple ICs on the 64's motherboard.

[+nanochess]

The C language is incredibly powerful to program machines with an instruction set that fits the language.

 

C language was designed with PDP-11 in mind (a 16-bit processor,) later it was adopted for 32-bit processors.

 

Of course, in PC most of us will remember the headaches of segments in 8088/80286 until came the pure 32-bit environment of 80386.

 

At this date almost nobody uses assembly language for higher-end processors, except for kernel routines, some graphics routines or video decompressors.

 

The Z80 and 6502 doesn't have the features required by C like stack easy to access, so the code tends to be inefficient.

 

Anyways, C is used with great success for Colecovision games (Z80) because there is enough base space for programming (32K,) while for 6502 and Atari VCS the 4K ROM leaves little space for C inefficiency, batari BASIC is more optimum.

 

For both processors the programmer will have to resort to assembly language when there is a need to squeeze in more features using up to the last byte. And there are many examples of excellent Atari, Commodore 64, Colecovision and MSX games written in pure assembler.

Edited January 14, 2014 by nanochess

[Mr SQL]

'Shawn Jefferson', on 17 Aug 2012 - 12:36 AM, said:

cc65 (www.cc65.org), has the concept of register variables (6 bytes of them), so you can use those to help speed up your functions.

 

That's also used in the GCC 6809 compiler. I would think that page 0 variables yield better results due to less shuffling in and out of page zero but you can't put everything in page 0.


Given what the 6502 has for registers, I can see why it's only for assembly. It would greatly simplify writing some assembly code for use with the compiler.

 

I think they must be talking about page 0 variables because there aren't 6 bytes of registers available; perhaps they imply the concept of "register variables" to mean they are faster, like registers, for being on the 0 page.

 

The 6809 can put everything on the 0 page because it can change the page.

[+Gemintronic]

For the generation that started with assembly C is a matter of suitability to the project. For resource constrained systems the answer is usually not C.

 

For the generation that started with BASIC C is a lesser evil. This attitude will only grow with time.

 

I'm not saying it's right Just one possible explanation if there's been a perceived shift.

[Stormtrooper of Death]

On the Atari 8bit, i started programming in Atari Basic, then in machinelanguage (yep, with an editor , entering Hex and mnenomic codes). I ended up programming in the German Atmas II assembler. My friends of the High-Tech Team mostly programmed in Mac-65. Yesterday, when i got my new second hand Atari 130XE, i tried some Atmas II programming. First since 20 years. I still rememberd the little colourbar code.

 

I never programmed in C or C++.

[danwinslow]

I started with C. Then I started dropping ML into my C. Now I use almost exclusively ML.

[Mclaneinc]

As a total novice programmer I started with BASIC and yes I did the Hello World thing (so sad) but people around me were stuck heavily into MC and the allure of trying it got to me and I hit it off with it (in my level of programming), I looked at all those other languages that were about at the time but I have to say they looked so damn complex, later on the Amiga I tried C but again found it too much for my small brain.

 

Hence me rubbish programmer but I had fun trying which is the important part..

 

Me and a mate actually made a multi boot clone with all fancy sprites like the EA loader etc around the screen, looked really nice but we like many got stuck in to another idea and it was never fully finished, shame, I was really proud of it.

[Creature XL]

For the generation that started with assembly C is a matter of suitability to the project. For resource constrained systems the answer is usually not C.

 

For the generation that started with BASIC C is a lesser evil. This attitude will only grow with time.

 

I'm not saying it's right Just one possible explanation if there's been a perceived shift.

 

Although you might be surprised that in the real world (embedded development) even simple 8-bit microcontrollers are coded in C.

Of course the low level HAL contains assembly like every other kernel as well. But the logic is pure "C".

Did that personally for a well known German company for a coffee maker

 

"We" coding the retro computers might have a different perception as we want to get the last out of the machine, so even the game logic must be in assembler because the IRQs needed for a cool display or routines for soft-sprites steal the rest of the cycles. At least when we are talking a "action" games.

 

The game "HORDE" which was present some days ago or card games (Poker, Black Jack, ...) or some simple puzzlers can be developed in C on the A8 when there is enough memory left besides all graphic and sound assets.

[adamchevy]

I started programming in C++ because that's what was offered for intro to programming at my local college. Since being interested in these older retro systems I have been learning assembler. My current goal is to learn how to program for the Z80. I was going to stick with C but I am also interested in the 6507. These are both documented very well, and this community is an excellent resource. I do find the shift from a compiled language to assembly a bit like reverse engineering my programming logic, but in a good way. The more I learn about assembler the more appreciation I have for this community and the homebrews I play.

 

[flashjazzcat]

I'm interested to know (as a fairly competent C programmer who nevertheless is very unskilled in C++) whether people find it more difficult coming to 6502 from C++, or if it is harder to do it the other way around (i.e. learn C++ when you have a background in 6502). To me, both C and 6502 seem very uncomplicated in comparison to C++, but then I have been coding in 6502 for 20 years and haven't really tried very hard with C++.

[danwinslow]

C++ is just C with a slightly crappy object layer welded on to it, so moving to it from C is more or less just learning the objecty bits. Going to 6502 from any high level language is a real stretch I think, but coming from C it's probably easier than coming from c++ or c#.

[JamesD]

...

The Z80 and 6502 doesn't have the features required by C like stack easy to access, so the code tends to be inefficient.

...

For both processors the programmer will have to resort to assembly language when there is a need to squeeze in more features using up to the last byte. And there are many examples of excellent Atari, Commodore 64, Colecovision and MSX games written in pure assembler.

Stack relative addressing, a 16 bit stack pointer and general purpose registers are pretty much required for really efficient C code.

Compiler support really didn't seem to be in the CPU designer's minds when most were designed at a time were an 8 bit CPU was only tied to 1K or 4K of RAM.

The 6809 was the first 8 bit CPU I know of that took operating systems and compiler support into account in the design and the 65802/65816 was sort of a me too rip off of the 6809 so they also support compilers fairly well. Compiler output for these CPUs still isn't perfect but it's way better than for the other 8 bit CPUs.

 

A C compiler that allocates space on page 0 (like GCC for the 6809) generates some fairly decent code in spite of the CPU not having general purpose registers. I'm sure the same could be done for other CPUs that have direct page addressing, I just haven't seen it done yet. That might fix a lot of the issues with the 6800, 6803 and 6502 code efficiency from existing C compilers.

FWIW, the movable direct page doesn't help a compiler much since it doesn't know where the code or data will be until link time and data may cross page boundaries without intervention by the programmer. With compiler support of a #pragma statement to define what to set the direct page to and forcing data to lie on a page boundary you could potentially take advantage of it.

Edited January 15, 2014 by JamesD

[ValkerieSilk]

I read Eduardo Mello uses Assembly over C. If you're low on mem as is always the case with retro homebrew probably assembly is the way to go so as to avoid the overhead. But man, assembly is brutal at least compared with C.

[JamesD]

I think they must be talking about page 0 variables because there aren't 6 bytes of registers available; perhaps they imply the concept of "register variables" to mean they are faster, like registers, for being on the 0 page.

 

The 6809 can put everything on the 0 page because it can change the page.

GCC uses register allocation and the 6809 code generator allocates those on page zero.

The 6809 doesn't have enough internal registers to take advantage of true register allocation at that level but direct page memory is faster than stack relative addressing so it makes sense to allocate the registers on page zero, then use some smarts in the code generator and peephole optimizer to make efficient use of actual registers.

 

FWIW, older 6809 C compiler output is filled with stack relative accesses. While it's perfectly legal and the 6809 supports it, it's just not as fast as direct page accesses so it's never going to be as fast as hand written assembly.

Edited January 15, 2014 by JamesD

[laoo]

C++ is just C with a slightly crappy object layer welded on to it, so moving to it from C is more or less just learning the objecty bits.

And from this popular misconception the "C-style programming in C++" has been born. Messy and crappy.

Proper and deep knowledge of C++ induces its own unique style that uses languages automation of low level stuff (RAII, exceptions) with strong abstraction and type correctness.

 

Regarding the topic, the C compiler producing 65c816 code could have very reasonable usage in memory rich accelerators (e.g. Rapidus). First 64kB could be used as a "Chip memory" (for Antic). Few kilobytes could be reserved for stack and other few for "scratchpad" using direct page addressing. The rest of few megabytes could be for code and data. It could permit producing much code that is not time critical. I've found few months ago a decent C compiler suitable for producing code for low-level 8-bit systems with the pluggable back-end subsystem. I don't remember the name now. I was thinking a bit about implementing 65c816 back-end for it, but of course it's too big task to find enough time for it being one person that could spend some free time for it.

 

EDIT: Found the compiler: http://sdcc.sourceforge.net/

Edited January 15, 2014 by laoo

[danwinslow]

And from this popular misconception the "C-style programming in C++" has been born. Messy and crappy.

Proper and deep knowledge of C++ induces its own unique style that uses languages automation of low level stuff (RAII, exceptions) with strong abstraction and type correctness.

 

Regarding the topic, the C compiler producing 65c816 code could have very reasonable usage in memory rich accelerators (e.g. Rapidus). First 64kB could be used as a "Chip memory" (for Antic). Few kilobytes could be reserved for stack and other few for "scratchpad" using direct page addressing. The rest of few megabytes could be for code and data. It could permit producing much code that is not time critical. I've found few months ago a decent C compiler suitable for producing code for low-level 8-bit systems with the pluggable back-end subsystem. I don't remember the name now. I was thinking a bit about implementing 65c816 back-end for it, but of course it's too big task to find enough time for it being one person that could spend some free time for it.

 

EDIT: Found the compiler: http://sdcc.sourceforge.net/

 

Popular misconceptions usually have a germ of truth. Originally, C++ was exactly C with an awkward object layer on top of it. It has since been greatly improved, but it remains somewhat awkward syntactically ( in my opinion ) although it is certainly an extremely capable language.

Edited January 15, 2014 by danwinslow

[JamesD]

...

Regarding the topic, the C compiler producing 65c816 code could have very reasonable usage in memory rich accelerators (e.g. Rapidus). First 64kB could be used as a "Chip memory" (for Antic). Few kilobytes could be reserved for stack and other few for "scratchpad" using direct page addressing. The rest of few megabytes could be for code and data. It could permit producing much code that is not time critical. I've found few months ago a decent C compiler suitable for producing code for low-level 8-bit systems with the pluggable back-end subsystem. I don't remember the name now. I was thinking a bit about implementing 65c816 back-end for it, but of course it's too big task to find enough time for it being one person that could spend some free time for it.

 

EDIT: Found the compiler: http://sdcc.sourceforge.net/

There are already some 65816 C compilers out there.

The SNES SDK includes one (TCC) but I've seen others. I think there is a mostly complete version of LCC that supports the 65816.

https://code.google.com/p/snes-sdk/

 

SDCC is one of the better efforts out there. It's a modern compiler rather than something based on Small C and the source code is much easier to follow than GCC. The register allocation in GCC is more sophisticated than SDCC though.

The SDCC devs are making progress towards full ANSI compatibility but for the moment it is still missing a few things.

The SDCC Z80 code generator is probably the best of all the supported processors and it generates good enough code that it has now replaced the old Z88dk C compiler which had many more years of development.

 

I'm not sure how SDCC compares with TCC or LCC for optimization, but that would depend largely on an actual implementation of an SDCC 65816 code generator.

I actually spent some time developing a new CPU target for SDCC... until work got in the way.

It's not too difficult to create new targets using an existing one just as a starting point as long as you understand how the compiler works and know enough about the other target's CPU. Keep in mind it would require some changes to the SDCC register allocation code to implement a target that uses page zero variables.

Edited January 16, 2014 by JamesD

[Kyle22]

Maybe somebody can comment on the Z80. There is a C for the ColecoVision. That's kind of amazing, though it's not self-hosted, using a PC. C on the Apple is self-hosted, though it's tough compared to cross development using a PC.

 

I am very out of practice on C, but I remember using BDS-C available here: http://www.bdsoft.com/resources/bdsc.html

 

I used it on a multi-user TeleVideo CP/M based system, and I really liked it. It seemed to be decently fast, and it is very easy to add your own assembly language functions. I used the SLR assembler and linker.

 

The SLR assembler package, along with the docs, and many other useful tools are here: http://s100computers.com/Software%20Folder/Assembler%20Collection/Assembler%20Collection.htm

 

It all started when I found this really cool program called Ataribus from the First Osborne Group (FOG) on Disk # 24 (which, UNfortunately, I can't find a link for right now). Basically, it is an SIO2CP/M program, written in C. I modified it to add lots of features, including UltraSpeed. I think (If I remember correctly) I got as fast as PoKey divisor 3 before I started having minor timing issues.

 

Overall, I think BDS-C is very useful on the Z80, especially when time critical functions are written in assembler.

[ilmenit]

SDCC is one of the better efforts out there. It's a modern compiler rather than something based on Small C and the source code is much easier to follow than GCC. The register allocation in GCC is more sophisticated than SDCC though.

The SDCC devs are making progress towards full ANSI compatibility but for the moment it is still missing a few things.

The SDCC Z80 code generator is probably the best of all the supported processors and it generates good enough code that it has now replaced the old Z88dk C compiler which had many more years of development.

 

6502 CPU is an ugly beast to target with ANSI C, because of available addressing modes. ANSI C programs rely on pointers to flat memory (no pages), support for nested structs and recurrence disallows a lot of optimizations, function parameters are passed by copying values to stack, large memory block (bigger than a page) can be allocated anywhere and addressed by pointers.

SDCC is very nice compiler and much better than CC65. However stuff mentioned above would cause a lot of problems even for SDCC. In my opinion the only option for lighting fast C compiler would be to limit the subset of supported C features, maybe with a special command line switch.

I really hope the ATALAN project will continue to improve - this could be a good C replacement for quick development for 6502.

Edited January 16, 2014 by ilmenit

[laoo]

 

6502 CPU is an ugly beast to target with ANSI C, because of available addressing modes.

Right. And therefore the SDCC discussion whas w.r.t. 65c816 that is much better target for a C compiler. Not ideal due to 6502 inheritance, but better.

[JamesD]

6502 CPU is an ugly beast to target with ANSI C, because of available addressing modes. ANSI C programs rely on pointers to flat memory (no pages), support for nested structs and recurrence disallows a lot of optimizations, function parameters are passed by copying values to stack, large memory block (bigger than a page) can be allocated anywhere and addressed by pointers.

SDCC is very nice compiler and much better than CC65. However stuff mentioned above would cause a lot of problems even for SDCC. In my opinion the only option for lighting fast C compiler would be to limit the subset of supported C features, maybe with a special command line switch.

I really hope the ATALAN project will continue to improve - this could be a good C replacement for quick development for 6502.

No question, parts of ANSI C are difficult to optimize. It was created at a time when code optimization was a bit primitive and they really didn't have that in mind. But instead of limiting C compatibility and defeating one of the purposes of using C in the first place, why not just use a language like Pascal?

Pascal is easier to optimize due to strict type checking, you can't declare new variables at any point in the code which results in less register and page zero manipulation. With a few of the newer extensions, it would target the 6502 about as well as you can expect.

I'm not a huge fan of Pascal and in fact, I have some major gripes with it, but if you aren't going to make a C compiler compatible with C... then it's not really C. On top of that you would need a whole set of special cases to improve the optimizer to support what you are suggesting.

I don't think such optimizations are where the greatest potential improvements for 6502 C code generation are though.

 

One of the benefits of allocating "registers" on page zero would be that you could potentially pass parameters on page zero as well. It's far from ideal but the 6502 just wasn't designed to support compilers and you can only expect so much from a compiler to make up for it. At some point you just have to decide that some code has to be written in assembly.

 

I would certainly encourage people to continue work on new languages but I think it would require less effort to extend an existing one like Pascal. There are certainly open source Pascal compilers out there that might be used as a starting point. One major advantage of using an existing language is there is an existing code base to borrow from.

[ricortes]

Just a few out of sequence thoughts. C is assembly language if you want it to be. Just use whatever output switch it takes to save the assembler source code.

 

I found this handy when learning assembler on different processors. Write a short snippet of code that does something you want it to do, run it through the compiler and see how it is done in assembly on the target processor. Makes sense to learn C in a teaching environment since you are forced to develop a lot of good habits followed by peeking at just what the source code generated looks like.

 

Every once in a while there is a 'which programs were written in <language X>" thread. Certainly one of the most influential in C was Castle Wolfenstein 3d. If I recall a blurb with the authors at Id, there was only a few lines of assembler for the video display in the entire program. When it came time to port it to the SNES, they used a hacked Orca C. Ditto for the ST platform with Dungeon Master being both influential to just about every CRPG that came after it and being written in C.

 

In the same vein as C is ~macro'ish assembler where you could save the assembler output if you want to, C++ did about the same thing when it started out except it output C! First pass of C++ compiler/preprocessor would output C code which would then be compiled to assembler which would then be assembled into object which would then be linked to the run time.

[thorfdbg]

No question, parts of ANSI C are difficult to optimize. It was created at a time when code optimization was a bit primitive and they really didn't have that in mind. But instead of limiting C compatibility and defeating one of the purposes of using C in the first place, why not just use a language like Pascal?

Pascal is easier to optimize due to strict type checking, you can't declare new variables at any point in the code which results in less register and page zero manipulation.

But even with Pascal, the problem of the call stack and its poor support on the 6502 does not go away. There is a reason why companies like Oss tailored specific languages like Action! just for the 6502. Global variables, or only static variables, no recursion, and you are fine. Of course, something like this could also be done within a language that has a syntax that is close to C.