Recently, I had the job of taking over someone's prototype development, and part of the system included C code to read RAW data from an SD card. Having recently written my own SD card code for the 6502, I figure it would be an easy project to do. It took me only a few hours to get SD access on the 6502 using assembly, and it is minimal code.

Well, after 2 days I finally gave up!
Bool this, struct that, misdirection, bloat, bloat, bloat!.... and for what!!??
Sorry, I just had to rant. Why would anyone want to write code like this??

I eventually downloaded the PIC assembly list and just coded the thing from scratch in 3 hours.
Didn't even know PIC assembly, and it was still easier than trying to follow C breadcrumbs!
The code went form at least 400 lines to about 30, and program memory usage was way down.

I have never been able to figure out why anyone though that C on a small uC was a good idea.
is there some draw to putting fluffy names on everything and simply writing a lot of code for nothing?
A uC can do nothing more than turn an IO on and off... it's just ones and zeros man!

Anyhow, I am so glad I am not doing it for a living.
Now back to 6502 assembly, where life is good!

Cheers!
Radical Brad

I haven't as well, but understand why such thinking exists.

In the book The C Programming Language (Prentice-Hall 1978), the authors reveal on page two that "...the vast majority of UNIX users (including one of the authors of this book) do not even know the PDP-11 assembly language." That is a very telling comment, especially when you consider that UNIX users in those days were not like the naive sorts who push a mouse around today and think they know their way around a computer. The authors of the book were the late Dennis Ritchie and Brian Kernighan. As Ritchie was the one who developed C, you can probably guess which of these two gentlemen didn't know the PDP-11 assembly language.

I strongly suspect the "vast majority" of PIC users don't know the PIC assembly language, but are familiar with C. C, like any other language, can be poorly utilized and although it is a "structured" language, it is certainly possible to write spaghetti code in C. C is today what BASIC was 30-odd years ago on the first and second generation of microcomputers. It stands to reason that a significant fraction of today's programmers don't really know how to write clean and efficient code in C, just as BASIC programmers back in the 1980s often knew nothing about good style and structure. It seems you have encountered just such a programmer.

Any high level language is inefficient when implemented on a small system, especially a µcontroller. The problem, of course, is most µcontroller programmers either don't know the device's assembly language or know it but don't know how to write economical and efficient code. The µcontroller manufacturers know that, and have produced C compilers so they can sell product to people who don't know assembly language. The predictable result is a programmer writing in C is not aware of how the underlying hardware works and ends up using a gazillion lines of code to say the cow jumped over the moon. Good luck on changing that!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

It mightn't be a problem with C at all - language is no barrier to bad code. If someone didn't quite understand the problem they are solving, the code will reflect that, even if it works.

But it's clear from our experience, seeking C compilers for 6502, that not all instruction set architectures are equally well suited as compiler targets. Indeed, the very simplicity and minimalism which makes 6502 easy to learn and easy to love may count against it as a compiler target.

It's good that people should understand computation at the lowest level - it's good if they've seen more than one way to do it - and it's also good that people should know how to organise their code and use their language well. But sometimes people haven't had the benefit of good teaching, or haven't had the time to concentrate on solving the problem at hand in a natural way, and the result is code that's a mess.

Which is to say, I wouldn't necessarily blame the language.

It also depends on the size of your project. I wouldn't consider writing a C compiler in assembly language, but something small, like a monitor is relatively easy to write in assembly.

The 6502 is quite unsuited to executing high level language constructs, and this makes writing assembly language for the 6502 more suitable for most projects than using a high level language. The 65C816 has features that makes writing compilers much easier, and therefore is more suitable for using C for.

C in particular is quite a complex language. Writing a C compiler is a very large task, whereas writing a Pascal compiler is much easier. C++ becomes a huge task to write a compiler for.

People do write operating systems in assembly language, but even then it is probably easier to manage a project of that size using a high level language.

High level languages are also easier to write maintainable code in. They make the intention of the code more obvious. A relatively simple line of C code, like this:



is a lot easier to read than the equivalent assembly code.

A modern compiler also requires quite a lot of tooling around it, like editors, shells, build tools, a linker and a runtime loader, which adds to the complexity and bloat. Whereas a basic interpreter, while many times slower, is much simpler to implement.

I am looking to write stuff stuff on propellor and will either use spin or C. Reasons for not using asm is it is I won't remember how it works in a year (and I find HLL easier to understand) and also there are many more code examples and prebuilt software to run on the cogs in spin/c than ASM. And if other people want to use it for the same reason spin/c would be better. Only reason I would go for ASM was speed or functionality that was easier/can only be done through ASM.

I am not unusual in this outlook on life So I guess that applies for the person who did the C on the micro controller for your project. I think in the 6502 world people just used to asm and forget outside most people don't know asm.

> I think in the 6502 world people just used to asm and forget outside most people don't know asm.

There are for sure some people like that, but best not to generalise too much.

I might do that in a macro, so it would still take only one line in assembly language and be quite readable, and yet it gives you total control of what machine code comes from it.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I like writing in assembler but there are times when a C (or Pascal or BCPL or 'add language of your choice') compiler just helps to get stuff done.

Generated code is not normally as fast or memory efficient as handwritten assembly but its usually fast enough, especially with today's super fast micro-controllers and you can always drop in a little bit of assembler for time critical jobs if you have too.

Complex data structures, control logic (e.g. lots of nested loops and conditionals) and maths are a pain to write in assembler (even with the structured assembly directives in my assembler). A compiler reliably cranks out the code for these kinds of things and all in fraction of the time it would take to do them by hand. With the added benefit the source is normally smaller and simpler to understand.

In the 80's I worked on big UNIX software projects on 16-20MHz 68000 and Sparc Workstations and we never looked at the generated code from our C and F77, there was always another deadline to hit. Some of my hobby projects use 70MIP RISC micro-controllers and I have to fight the urge to look at the assembly sometimes. If something is too slow its usually the wrong choice of algorithm rather than the compiler.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Didn't mean it like that.

I meant more an empirical observation that people outside of 8bit processor and micro controller world wouldn't even consider Assembly to program in. So when they move to bare metal they use what they know.

I think I can go with that! I'm in the same camp as BitWise - I will sometimes look at a compiler's assembly output to see what is going on.

I've been using C for commercial uC projects since the late '80s and can appreciate the benefits of a HLL when up against a deadline. However, I have seen engineers get carried away with the concept of building a grand "Master Control Program" (seriously, that's what one lead engineer called it) when a focussed, straight forward implementation is not only easier to understand, it is a great deal faster and smaller. I can imagine your inherited C implementation was over-designed with the idea for drop-in file system modules, self-driving car modules (the obvious extension to an SD card reader), etc. And unless they've done this before, their first attempt probably got it wrong and would need much modification in the future. So why not start with a simple, basic implementation and grow its feature set over time?

Yeah... that's what my 6502 computer needs.
Might as well toss in a missile guidance module while I am at it.
To be sure that I am "hip", I have to include an Arduino in there someplace, and then put up a Wordpress site with a dozen "wedgits" to show it all off!

I consider C to be a software version of a Rube Goldberg machine.

Brad

I find 'C' to be a exceptionally well suited language for low level platform code, and that sentiment is shared by almost everyone in the embedded space, at all levels of experience. When you read a line of 'C', a competent programmer with target architecture knowledge can SEE the underlying cost of the code (unlike, say, C++ where "a = b + c" can invoke a number of different class methods). [I don't want to go off on a C++ rant, though, as I've used it on large embedded RTOS systems and, with some team rules in place about such things, it's a fine choice that can greatly improve program structure and modularity. You just have know going in what you're trying to accomplish, and reign in engineers trying to demonstrate how clever they are.]

Language choice is a very personal thing, though. I've poked around at Forth for years, but I've never gone all-in for a whole project, and I suspect that's why I still find it to be so unusable, whereas competent Forth people can't stop themselves from extolling its virtues. I don't know better than Forth experts... I've just failed at it (and that's ok).

I'll choose 'C' for small microcontrollers if it makes sense... and that's where judgement comes in. I once had a PIC12 project that amounted to under 50 lines of assembly - it would have taken longer to install and learn how to use the compiler than completing the project. I had an XA-G49 project that amounted to a couple of thousand lines of assembly. I wish I'd had a 'C' compiler for that one, as it was pretty complex and, barring a few low-level details, doing it in assembler was unnecessary... but management didn't want to buy a compiler, so all I had was an open source assembler. I even prototyped the beginnings of a (very simple) Forth subset to avoid doing the whole thing in assembler, but in the end I decided that well commented assembly would be easier for other engineers to maintain than Forth, which I found (after a few carefully asked questions) nobody had even heard of. Literally. Zero other engineers in the pool I polled (most born in the mid 60s - mid 70s). Asking them to pick up a foreign assembler is one thing, but I couldn't ask them to maintain a foreign paradigm.

When I first started programming back in the early 80s, knowing assembler (e.g. for the Z80 or 6502) made you a God among men (or at least a teen-God among other teens). Everyone knew BASIC and could do little things. Knowing assembler earned you serious kudos. Assembler was smaller, faster and milked every ounce of performance out of the machine. As I've progressed through my professional career, I've come across fewer and fewer people who enjoy assembly programming, and over time the number of new graduates even exposed to it on a practical level has now reduced to near zero. I remain "that guy"... the one you go to for initial processor startup and to debug gnarly low level problems. But I don't choose to write in assembly language unless I really have to.

Nowadays I'm rarely trying to squeeze every cycle or byte out of the machine - even microcontrollers. These things are almost always bigger, better and faster than the work I'm trying to do, so I optimize for development time and maintainability by other engineers with a range of experience. Demonstrating how gosh darn clever I am is pretty much always the wrong choice.

TL;DR: 'C' is great.

Mostly what sark02 said. C is a great language for low-level work. The problem isn't the language itself, the problem is A. modern compilers which don't have the foggiest clue how to optimize for anything other than x86/x64 because the developers are too busy adding support for features the language doesn't need in the first place, and B. programmers who naively trust the compiler to produce the best code and never bother to check what it's actually outputting, let alone hand-optimize it with tweaked algorithms or judicious use of assembly language. In a modern desktop PC environment, that's merely annoying and only likely to cause suboptimal performance; in a limited environment like a vintage 8/16-bit computer or a microcontroller, it can be crippling.

I was one of the leads on an embedded system whose main management process I named "MCP" after the Tron "Master Control Program" (and my username, "Sark" is also from Tron). Don't be hatin'.