Does anybody learn C any more?

[rstofer]

And a Real Man can write FORTRAN code in every language.

That's exactly what my grad school adviser said after I wrote an 8080 assembler in PL/I.

With an adequate amount of white space separating 'thoughts' of code and indentation of DO loops, Fortran can look pretty good.  Most of it does not.  Then again, there is going to be a lot of array subscripting because we're basically doing math and function calls look exactly the same.

I still like 'simple' languages like Fortran77 (or earlier), I don't think I'll ever use the object features of later incantations.  Do we really need to overload operators in Fortran?  Apparently...

[djacobow]

The "tab" alias "&#9" alias "\t" alias 0x09 has been always forbidden and banned in every task I have ever done in Avionics.

Before committing a source to Doors (it's like Git) I have to filter the file and replace each 0x09 with 0x20, and it's has been so boring that the first thing I did was a C program that does the job, and does format as well the text too according to a template.

Yup. Historical reasons aside, the tab character just has no place in a modern text file! Once you are rid of them indenting becomes easier, not harder.

[alank2]

I hate tabs much more than semicolons!!!

[rsjsouza]

Notepad++ does a search and replace of EOL, Tabs to spaces, etc. on a single file.
It can also do a search and replace these special characters in all files in a subdirectory. I do this all the time:

DOS to *NIX EOL


Tab to three spaces

[Kleinstein]

It seems like a lot of people used assembly to get top performance back in the day

Yup. If you love RISCOs by Acorn, the first releases of their RISCOS were written entirely in arm assembly with a couple of scripts written in Acorn-basic. The same applies to the first AmigaOS classic.

I have recently bought a book written by a few writers that usually wrote for Dr. Dobb's Journal (DDJ). It's about 200 pages, a true collection of routines written in 68k and hc11 assembly. Some are very nice, neat, and useful, and there is the full source of a gw-basic, which was originally written for the 68k Tutor board.

Those lists show there were some tips and tricks to organize the code in a portable way, like the choice of a documented way to attribute a meaning to each register, or to some special location of the ram, or even more interesting, a way to define system traps and system services. And, of course, there are also macros, even for the earlier Acorn DDE that did support them.


Those programmers were more well organized than me about "how you manage your code" 

Writing good ASM code needs a lot of additional, soft rules to organize things and comment things.
C also need such additional coding conventions to prevent the code to get unreadable and no longer portable. Just the C language as enforced by the compiler is only a small part. The next part are the standard libraries. Finally it takes some more or less conventional rules on how to name variables, write comments and indent things. Especially the usual plentiful use of #define in C code can cause quite some confusion, if used different than normal.

It may be more important to learn those more informal rules than the actual C languish.

[Berni]

Notepad++ does a search and replace of EOL, Tabs to spaces, etc. on a single file.
It can also do a search and replace these special characters in all files in a subdirectory. I do this all the time:

Or just use the built in indentation handling of a lot of text editors, here is sublime for example:


You get the menu by simply clicking the indentation indicator in the status bar, letting you covert any sort of indentation you would want and it autodetects what kind of indent to use by analyzing the file when opening it. When editing it doesn't matter if you use space or tab, the editor always puts in the correct indent type for what it is set to use.

[westfw]

I have to admit that every time I think something like "what the embedded ARM world needs is a port of avr-libc, because newlib-nano is just too huge and bloated (even though it's better than newlib)", or "I now know about six different ways to make Arduino's DigitalWrite() a lot better, maybe I can sneak them into the new XXX core where there aren't any "legacy issues"", I self-censor myself and don't say anything because I fear that everyone under 40 or so will laugh at the very idea!

(Well crap.  Make that "amost every time."  )

[legacy]

It may be more important to learn those more informal rules than the actual C languish.

Definitively! This is the first thing in my head when I came across to the VxWorks source. Windriver spent a lot of time and resources on documenting how to write stuff, and they are still paying guys to keep sources aligned with their templates.

If you randomly open a file about the BSP or a part of the kernel or even application, you will always find things written strictly according to the template, which means that if you want to write your own driver for something (in my case I am on a USB-can driver for a customer) you have to know how to make it *compliant* to the template, which also tells you *how* you have to name variables and functions.

Abuses of #define's are not tolerated by the internal QA, so it can't be "WxWorks compliant".

[coppice]

I have to admit that every time I think something like "what the embedded ARM world needs is a port of avr-libc, because newlib-nano is just too huge and bloated (even though it's better than newlib)", or "I now know about six different ways to make Arduino's DigitalWrite() a lot better, maybe I can sneak them into the new XXX core where there aren't any "legacy issues"", I self-censor myself and don't say anything because I fear that everyone under 40 or so will laugh at the very idea!

(Well crap.  Make that "amost every time."  )

The real problem is that so many young engineers have only ever known bloated solutions and keep saying chip X can't do job Y when it just needs some attention to detail to make the job fit very nicely. If you are working on low volume products this attitude is OK, as simplifying development counts for more than minimum BOM. As the volumes rise it puts companies at a real competitive disadvantage.

[Kjelt]

The real problem is that so many young engineers have only ever known bloated solutions and keep saying chip X can't do job Y when it just needs some attention to detail to make the job fit very nicely. If you are working on low volume products this attitude is OK, as simplifying development counts for more than minimum BOM. As the volumes rise it puts companies at a real competitive disadvantage.

Has nothing to do with young engineers, has everything to do with management and stakeholders.
They want fast turn around development, each year something new so consumers buy again.
You can't have fast 4 month R&D cycles && cost optimization && (code) quality.
If you choose a platform based on a 4 year platform lifetime and you need to add features each half year that nibbles of the CPU and memory reserve, you better make sure your platform can handle that growth.
Twenty years ago there was a 2 yr cycle, one year development, half year production optimization and half year testing, everything to make it as robust and cost / production effective as possible.
Gone those days are.

[rsjsouza]

You get the menu by simply clicking the indentation indicator in the status bar, letting you covert any sort of indentation you would want and it autodetects what kind of indent to use by analyzing the file when opening it. When editing it doesn't matter if you use space or tab, the editor always puts in the correct indent type for what it is set to use.

Yes, the editors are quite advanced these days. However, when working with multiple people touching the same source code across multiple OSes, I usually want to be sure the files are actually using the same special/invisible characters. YMMV, but in my case I had enough compatibility problems in the past when consuming the same files on three OSes and having all sorts of weird errors.

[coppice]

The real problem is that so many young engineers have only ever known bloated solutions and keep saying chip X can't do job Y when it just needs some attention to detail to make the job fit very nicely. If you are working on low volume products this attitude is OK, as simplifying development counts for more than minimum BOM. As the volumes rise it puts companies at a real competitive disadvantage.

Has nothing to do with young engineers, has everything to do with management and stakeholders.
They want fast turn around development, each year something new so consumers buy again.
You can't have fast 4 month R&D cycles && cost optimization && (code) quality.
If you choose a platform based on a 4 year platform lifetime and you need to add features each half year that nibbles of the CPU and memory reserve, you better make sure your platform can handle that growth.
Twenty years ago there was a 2 yr cycle, one year development, half year production optimization and half year testing, everything to make it as robust and cost / production effective as possible.
Gone those days are.

This is small production volume thinking. If you are working on big production volume items the margins are usually so small you have to get every cent out of the BOM to survive.

[0culus]

You get the menu by simply clicking the indentation indicator in the status bar, letting you covert any sort of indentation you would want and it autodetects what kind of indent to use by analyzing the file when opening it. When editing it doesn't matter if you use space or tab, the editor always puts in the correct indent type for what it is set to use.

Yes, the editors are quite advanced these days. However, when working with multiple people touching the same source code across multiple OSes, I usually want to be sure the files are actually using the same special/invisible characters. YMMV, but in my case I had enough compatibility problems in the past when consuming the same files on three OSes and having all sorts of weird errors.

Git does a very good job of normalizing line endings when files are checked in, and then returning them to the correct line endings for the system they are subsequently checked out on.

[Kjelt]

This is small production volume thinking. If you are working on big production volume items the margins are usually so small you have to get every cent out of the BOM to survive.

What do you call small? This was experience with +/- 600k to 1 million products/year  @ BOM $15 a piece.

[brucehoult]

Also in terms of stack, how do you think pretty much all modern CPUs call a subroutine? They all have a register that is used as a stack pointer and the instruction for returning from the subroutine requires the return pointer to be sitting on the stack.

Hardly ANY popular ISA designed since 1980 requires a subroutine return address to be sitting on the stack!

It's certainly not true for SPARC, MIPS, ARM, PA-RISC, PowerPC, Alpha, Itanium, RISC-V, SuperH which all store the return address for a function call into a register, and the return instruction takes it from the same register.

AVR and MSP430 do store/take return addresses on the stack. Exceptions to the rule.

x86, m68k, 8080, 8051, z80, 6800, 6502, 6809, VAX all store return addresses on the stack. They were all designed in the 1970s -- 40+ years ago!

[magic]

Yes, but the discussion was about MCUs, so AVR, PIC and 8051 are perhaps more relevant than DEC Alpha or Itanic
ARM, MIPS - sure.

The original complaint was that using C on those chips forces the use of stack, as if stack weren't already required for function calls by the ISA of most MCUs.

[Berni]

Also in terms of stack, how do you think pretty much all modern CPUs call a subroutine? They all have a register that is used as a stack pointer and the instruction for returning from the subroutine requires the return pointer to be sitting on the stack.

Hardly ANY popular ISA designed since 1980 requires a subroutine return address to be sitting on the stack!

It's certainly not true for SPARC, MIPS, ARM, PA-RISC, PowerPC, Alpha, Itanium, RISC-V, SuperH which all store the return address for a function call into a register, and the return instruction takes it from the same register.

AVR and MSP430 do store/take return addresses on the stack. Exceptions to the rule.

x86, m68k, 8080, 8051, z80, 6800, 6502, 6809, VAX all store return addresses on the stack. They were all designed in the 1970s -- 40+ years ago!

Okay i did put it a bit broad. Yeah there are architectures that use things like a link register to hold the return address, but as i have explained later on even those eventually end up pushing it on the stack as soon as functions become complex enough. You are typically required to restore registers to there previous state before finishing a subroutine. The easiest way to preserve the link register is to push it on the stack, do your stuff (including call other subrutines), pop it back off the stack and return to it. So in more RISC like architectures you end up doing the same as CISC does, just doing it step by step instead of a magical single instruction. Yes you can avoid putting it on the stack if your subroutine never calls other subroutines but all practical programs do that at some point.

It's a bit of a optimization to skip stacking the return address on small simple functions, but its even more of an optimization to simple tell the compiler to inline the function rather than calling it, and CISC like systems that offer the magical stack instruction for returning can also be made to call and return in the RISC like way of using a link register.

You can write programs without using a stack at all, but then again you can also compute everything with only a single accumulator register and a few bitwise instructions. But just because it can be done in a simpler way does not automatically mean its a good way of doing it. And a stack is one of those things that makes life a lot easier.

[brucehoult]

Also in terms of stack, how do you think pretty much all modern CPUs call a subroutine? They all have a register that is used as a stack pointer and the instruction for returning from the subroutine requires the return pointer to be sitting on the stack.

Hardly ANY popular ISA designed since 1980 requires a subroutine return address to be sitting on the stack!

It's certainly not true for SPARC, MIPS, ARM, PA-RISC, PowerPC, Alpha, Itanium, RISC-V, SuperH which all store the return address for a function call into a register, and the return instruction takes it from the same register.

AVR and MSP430 do store/take return addresses on the stack. Exceptions to the rule.

x86, m68k, 8080, 8051, z80, 6800, 6502, 6809, VAX all store return addresses on the stack. They were all designed in the 1970s -- 40+ years ago!

Okay i did put it a bit broad. Yeah there are architectures that use things like a link register to hold the return address, but as i have explained later on even those eventually end up pushing it on the stack as soon as functions become complex enough.

Yes of course, but that is typically far fewer than half of all function calls. Often it will be 10% or less as most functions that call other functions either call more than one of them or else call the same one repeatedly. Functions that only call one other function are I'd say more likely than not to be able to do that as a tail call (i.e. just a jump, no return) as they're more likely to be fiddling with the arguments than fiddling with the return result.

You are typically required to restore registers to there previous state before finishing a subroutine.

Some of them. RISC-V, for example, gives you 15 registers (a0-a7, t0-t6) that a function can use without restoring them, which very often reduces the memory load of leaf functions (which is most functions, as pointed out above) to only the absolute essentials of explicitly accessing arrays or pointer structures in the actual source code.

The easiest way to preserve the link register is to push it on the stack, do your stuff (including call other subrutines), pop it back off the stack and return to it. So in more RISC like architectures you end up doing the same as CISC does, just doing it step by step instead of a magical single instruction. Yes you can avoid putting it on the stack if your subroutine never calls other subroutines but all practical programs do that at some point.

Absolutely! If you do need to, which isn't actually all that often, dynamically. It's true that if you have a link register then you need extra instructions to save and restore the link register, but an advantage is you can do those any time you like, when it's convenient, for example re-loading the link register a few instructions before the actual return, so that you already have it when you need it. You can also avoid the save and re-load on any execution paths through the function that don't actually call another function.

It's a bit of a optimization to skip stacking the return address on small simple functions, but its even more of an optimization to simple tell the compiler to inline the function rather than calling it, and CISC like systems that offer the magical stack instruction for returning can also be made to call and return in the RISC like way of using a link register.

Sure, but you have to be careful with inlining. On small systems total code size is often critical, and even on bigger ones excessive inlining destroys the effectiveness of the instruction cache.

Learning that avoiding the "magical" CISC instructions on VAX and IBM 370 actually made programs up to two or three times faster on the same machine was exactly how RISC got started :-)

You can write programs without using a stack at all, but then again you can also compute everything with only a single accumulator register and a few bitwise instructions. But just because it can be done in a simpler way does not automatically mean its a good way of doing it. And a stack is one of those things that makes life a lot easier.

I would never suggest that! The stack is a fantastic invention and the advent of instruction sets that made it natural and easy to use it was one of the biggest advances in computer instruction sets. Making PIC code natural and simple (which x86 *still* doesn't do!) is another. And the development of first index registers (full absolute memory address in the code, and small array index in a register) and then base registers (full memory address in a register, and small offset in the code) is the 3rd.

The trick is in finding the minimal instruction set that gives all the nice features you want (recursion, PIC, stack, heap, dynamic linking, virtual functions, switch statements) with maximum performance, minimum energy usage, and minimum code size.

[Berni]

Yep all valid points.

What i was trying to say is that its very hard to have no stack at all in modern programing (to the argument that C heavily relies on the stack).

Yes there are cases where you can optimize away the stack and even make things faster, but it doesn't cover all the use cases so a stack still is needed for some of them. In some cases the stack reduces the memory footprint since it provides a spot for functions to store local variables without statically allocating them somewhere (And also breaking recursion with that). Since its so prevalent there is almost always a dedicated stack pointer register in CPUs, even if they are designed for avoid using the stack for certain things.

There are more arguments to be made against having a heap, but again for some use cases its a solution that works well.

I do have high hopes for RISC-V since its one of the very few architectures that does not drag on all sorts of legacy crap, so it can be designed from the ground up to fit our modern computing needs and efficiently use the abundance of transistors. On top of it all not being chained down by heavy licensing fees of the creator.

[brucehoult]

Yes there are cases where you can optimize away the stack and even make things faster, but it doesn't cover all the use cases so a stack still is needed for some of them. In some cases the stack reduces the memory footprint since it provides a spot for functions to store local variables without statically allocating them somewhere (And also breaking recursion with that).

Sure, LIFO is a very common allocation pattern, and a stack is perfect for managing that.

Since its so prevalent there is almost always a dedicated stack pointer register in CPUs, even if they are designed for avoid using the stack for certain things.

Interestingly, in the base RISC-V instruction set (32 bit opcodes) there is no stack pointer and no link register. All registers (except x0) are identical and you can use any of them as a stack pointer or link register as you wish. Have multiple stacks! If you only have a limited depth of subroutine calling and no recursion (as some are advocating) then you can use a different link register for every level of function -- no need to save and restore them! And keep a few for function calling in interrupts too, if you want.

The optional compressed instructions do make assumptions about where the stack pointer and link register are. And some cores with branch prediction assume that x1 and x5 are used as link registers.

I do have high hopes for RISC-V since its one of the very few architectures that does not drag on all sorts of legacy crap, so it can be designed from the ground up to fit our modern computing needs and efficiently use the abundance of transistors. On top of it all not being chained down by heavy licensing fees of the creator.

I'm kinda hoping it will be successful too :-)

[SiliconWizard]

You can't do without a stack unless you want to code as a huge spaghetti monster.

What exactly would "no stack at all" mean? Try and imagine any program that's more than a dozen lines without any stack. That would basically mean not call/return (or just one level) and no allocated local variables (only fixed in memory, or using only registers). Not something I'd want to deal with for any serious work. That's seriously limited. I'll leave that to whoever likes it.

Now the ability to handle several "stacks" concurrently is interesting (but not necessarily any "safer", as it adds complexity.)

One simple approach that has been used on some MCUs/CPUs is to have a dedicated stack as a return stack. It basically prevents many of the potential stack corruption issues leading to the potential execution of unwanted code. I think mixing return and data stacks in a single stack has been a serious mistake.

[magic]

If you only have a limited depth of subroutine calling and no recursion (as some are advocating) then you can use a different link register for every level of function -- no need to save and restore them!

Oh yes, and each function needs to be written to work at one particular call depth and use the right link register. Screw something up and you are returning to a wrong address. Gonna be fun

[westfw]

You might also ask exactly what "having a stack" really means.
We mentioned ARM, MIPS, and RISC-V as not using the stack for the bottom level of subroutine linkage.  But they each have general purpose registers with indexed addressing, so it's trivial to implement one or more stacks, and the ABI specifications call for doing so.  Usually there is a designated SP register (even though other registers can be used as stacks, nearly as easily.)  Being able to use the SP as an index register makes stack frames for local variables much easier.

At the other end of the scale, you have chips like the 8bit PIC microcontrollers, with a limited depth stack implemented in hardware, that is good ONLY for storing the return address of "call" instructions (and Interrupt return addresses.)  Really annoying, if you're used to having better.  And yet, plenty of useful products have been created using those...

I'm pretty sure I've used compilers (ie for Fortran) that didn't use stacks.  Each subroutine had an area to store the return PC and any registers that needed to be preserved, and another area for input parameters.  It works fine if you don't need recursion, and all of your memory is RAM, anyway...

[brucehoult]

If you only have a limited depth of subroutine calling and no recursion (as some are advocating) then you can use a different link register for every level of function -- no need to save and restore them!

Oh yes, and each function needs to be written to work at one particular call depth and use the right link register. Screw something up and you are returning to a wrong address. Gonna be fun

Of course this needs care! Basically calling each function needs to use Link Register #N where N is the maximum of the LR numbers for every function that calls it, plus 1. Trivial for a compiler to do.

It's far easier to just use a stack, of course.

The RISC-V ABI defines register x5 (aka t0) as a secondary Link Register. It is used for certain simple runtime library functions to not disturb the standard Link Register. One example is the subroutines that are used by gcc and clang if you give the -msave-restore option to save registers on the stack, or to restore them and return, instead of having a store-multiple instruction. It can also be used by things such as transcendental functions, or code to emulate multiply or divide, although it is not used for that at present.

[rstofer]

I'm pretty sure I've used compilers (ie for Fortran) that didn't use stacks.  Each subroutine had an area to store the return PC and any registers that needed to be preserved, and another area for input parameters.  It works fine if you don't need recursion, and all of your memory is RAM, anyway...

In the far distant past (introduced in '65), the IBM1130 didn't have enough registers to even contemplate having a stack so...

The first word of every subroutine was used to store the return address.  There was a BSI instruction (Branch and Store IAR) that placed the return address in the first word of the called subroutine and execution continued with the next work.  As a single thread machine this worked ok as long as the interrupt handlers weren't re-entered and that  couldn't happen based on the hardware design of the interrupt system.

On exit from a subroutine, the code issues a BSC <indirect> instruction Branch or Skip on Condition <indirect> with no condition and pointing to the saved return address.

The first word of each subroutine, by convention, was coded as

ENTRY: DC *-*

Define Constant of the Program Counter minus the Program Counter (obviously 0) but it was a nice flag.  It told you right up front that something was going to be stored there.  It wasn't simply a constant of 0.

I guess you had to be there to actually like the scheme.  Of course, once DEC machines came along with more registers and more addressing schemes, you might want to throw rocks at the 1130.  But it all worked and I still use my FPGA implementation to this day.

And the Fortran compiler had 27 phases (passes) and the entire source and resulting executable had to fit in memory.  Intermediate files weren't used because the compiler had to work from paper tape on some of the smaller machines.