Who should write embedded software?

[dannyf]

- our architecture had an unfortunate quirk in that ISRs attached to interrupts above a certain priority level could not be written in C; They had to be in assembler,

That makes zero sense, as the machine has no way of knowing how the binary code it executes is generated from assembler, C, or some other languages.

[Kjelt]

That makes zero sense, as the machine has no way of knowing how the binary code it executes is generated from assembler, C, or some other languages.

Depends on the micro and the compiler I think. It can make sense, we had the same problem with ISR's that the c compiler created, the compiler would insert it's standard code (push) before the first line of c but due to a bug in the micro we needed to do something directly at the entrance of the ISR but the compiler wouldn't let us so in that case we also had to write the ISR's in assembly. The next version of the compiler solved this bug however so we could use it again.

[dannyf]

The next version of the compiler solved this bug however so we could use it again.

That's the point, isn't it? The fact that you have to write in assembly because of a buggy compiler isn't a valid basis to say that your hardware requires coding in assembly.

[Kjelt]

The next version of the compiler solved this bug however so we could use it again.

That's the point, isn't it? The fact that you have to write in assembly because of a buggy compiler isn't a valid basis to say that your hardware requires coding in assembly.

You have your point.
BTW it was a hardware bug and when it was finally in the errata sheet of the micro it took the compiler vendor another half year to implement and release that version and you know as well as me that a product SW team will not switch instanteneously to the newest compiler version each and every time.

[dannyf]

a product SW team will not switch instanteneously to the newest compiler version each and every time.

I do that all the time. It pays to have somebody else to try out new compilers or new libraries first.

[djacobow]

No, it makes perfect sense, you just lack the breadth of experience with different processor architectures.

This particular processor architecture used register windows and had an ABI tailored to them. Essentially the physical registers of the machine become the top of the stack and only a portion of them are visible to the code at any one time. When a function makes a call or a return, the window is adjusted appropriately. The window is usually adjusted so that some old and new registers overlap. This allows a place to pass parameters for free. After a series of successive calls or returns, it may be necessary to copy registers to/from the real stack in memory, because of register underflow or overflow (you have run out of registers to slide the window down or up). In this case, the processor raises a window exception and an exception handler (essentially, an ISR) makes the appropriate copying and adjustment.

In this architecture, it was possible to set interrupt priorities higher than the window exception handlers, hence, there was no easy way for a higher priority interrupt handler to know the state of the stack/windows and adjust appropriately. Moreover, even if such an handler simply saved away all the state, it would still need to set up its own stack and that stack would have to follow a different calling convention, since the window exceptions will not fire inside the higher priority ISR.

This scheme may sound pretty bad to you, but it represents an interesting tradeoff. Because of windowing and the fact that most programs show good "call stack locality," register windowing with overlap is a strong overall performance win, at the expense of somewhat unpredictable call/ret performance (which is why higher than window exception ISRs are allowed) and the unfortunate aspect of ISRs that can't respect the C ABI.

It's a successful but "stealth" architecture, often used in processors that are deeply embedded and not typically exposed to system programmers. They have shipped billions of cores, most as DSPs for video and audio, and for higher end baseband processors.


-- dave j

- our architecture had an unfortunate quirk in that ISRs attached to interrupts above a certain priority level could not be written in C; They had to be in assembler,

That makes zero sense, as the machine has no way of knowing how the binary code it executes is generated from assembler, C, or some other languages.

[dannyf]

...that can't respect the C ABI.

That would be the first computer in human history that could tell if it is running code generated by C or assembly.

[djacobow]

...that can't respect the C ABI.

That would be the first computer in human history that could tell if it is running code generated by C or assembly.

SPARC, AMD 29k, and i960 all used windows. I don't know what their spill/fill exception systems were, but all started as microprocessors (not microcontrollers), so I'd wager they did not have sophisticated interrupt systems, at least in early implementations, thus obviating this issue. The architect of my company's processor was pushing some "main processor" kinds of idea for performance, but it needed to work in more traditional embedded systems with lots of high frequency interrupt activity, so this system sort of split the baby.

[dannyf]

SPARC, AMD 29k, ...

So? None of that explains how the architecture made it impossible to run C code.

Now matter how much history you invoke, you still haven't explained how a machine could tell if the binary code it is executing comes from a C compiler or assembly compiler.

No amount of history or fancy words can alleviate that.

[djacobow]

There are two problems:

1. the ISR is starting out in an environment without a C stack. It could set one up itself, but it needs to take care that it is not nested in another ISR that has also done the same

2. The call and return instructions are designed to be able to throw exceptions. Except when you are in a high priority interrupt, they can't.

I don't know what you're talking about an architecture that can tell how a binary was generated. It doesn't matter how the binary was generated. It matters that state of the machine when the code executes. Is that not clear? In one state, the machine's hardware will support the ABI, in another state, it won't. The high-priority ISRs operate in the latter state.

ABIs are arbitrary, and one could create an ABI for this architecture that made no use of register windowing at all. Then the C compiler or anything or anyone else could generate code for /that/ ABI. That would solve this problem, but would have a huge performance impact by forgoing the windowing mechanism.

SPARC, AMD 29k, ...

No amount of history or fancy words can alleviate that.

No amount of insults will make up for the fact that you seem incapable of realizing that other people know things you don't.

[dannyf]

There are two problems:

I think there is only one problem: How does any of that explain the following:

our architecture had an unfortunate quirk in that ISRs attached to interrupts above a certain priority level could not be written in C;

I can understand that a poorly written C compiler couldn't generate code for a particular piece of hardware. But how you can go from there to conclude that no code written in C can run on that architecture?

As to your personal attack, you can keep it to yourself.

[djacobow]

I can understand that a poorly written C compiler couldn't generate code for a particular piece of hardware. But how you can go from there to conclude that no code written in C can run on that architecture?

As to your personal attack, you can keep it to yourself.

I said that ISRs could not be written in C, which for all practical purposes is true. I then explained why this is so: that native C linkage mechanism would not work inside high priority interrupts.

Yes, uncle, I admit, you got me. It is possible that C code could run. Just NOT CODE FROM A COMPILER THAT USED THE PRIMARY CALL/RETURN CAPABILITIES PROVIDED BY THE PROCESSOR, a major performance feature of the architecture. Such code also could not call functions generated by a compiler that used such call/return facilities.

So, you could either use a compilation system with a custom ABI that performed very badly, or you could use one compiler for non-interrupt code and another compiler for the interrupt code, as long as neither tries to call the other, or you could write the high priority ISRs in assembler -- and even then the ISR could not call back into the "normally generated" C code.

It was not a matter of a "poorly written C compiler."

[dannyf]

ISRs could not be written in C ...

Except that your explanation doesn't hold water: nothing you said suggests that a C compiler couldn't be written to generate code to run in the isr.

It is entirely possible, and it sounds increasingly likely here, that the architecture is such that that particular C compiler cannot generate code to run on it. But that's quite different from saying that no C compiler can generate code to run on it.

[Bassman59]

ISRs could not be written in C ...

Except that your explanation doesn't hold water: nothing you said suggests that a C compiler couldn't be written to generate code to run in the isr.

It is entirely possible, and it sounds increasingly likely here, that the architecture is such that that particular C compiler cannot generate code to run on it. But that's quite different from saying that no C compiler can generate code to run on it.

He actually said that "ISRs above a certain priority could not be written in C." Everything else could be written in C.

[djacobow]

The explanation holds water because it is correct.

I said a C compiler could be written to generate code to run in the ISR. I also said that performance of code from that compiler would NECESSARILY be awful, and would be incompatible with the C code written to run in the ABI the machine was designed to run.

Here is exactly where I said this:
"
Yes, uncle, I admit, you got me. It is possible that C code could run. Just NOT CODE FROM A COMPILER THAT USED THE PRIMARY CALL/RETURN CAPABILITIES PROVIDED BY THE PROCESSOR, a major performance feature of the architecture. Such code also could not call functions generated by a compiler that used such call/return facilities.
"

This is absolutely true. I'm sorry you don't believe it, but I can't do anything about that. Fortunately for me, hundreds of customers designing multi-million gate SoCs with our IP were able to do understand the tradeoffs and design around them.

ISRs could not be written in C ...

Except that your explanation doesn't hold water: nothing you said suggests that a C compiler couldn't be written to generate code to run in the isr.

It is entirely possible, and it sounds increasingly likely here, that the architecture is such that that particular C compiler cannot generate code to run on it. But that's quite different from saying that no C compiler can generate code to run on it.

[dannyf]

I said a C compiler could be written to generate code to run in the ISR. I also said that performance of code from that compiler would NECESSARILY be awful,

Before you get too far, here is exactly what you said:

- our architecture had an unfortunate quirk in that ISRs attached to interrupts above a certain priority level could not be written in C;

That's some "gymnastics" to reconcile the two.

[nctnico]

The explanation holds water because it is correct.
I said a C compiler could be written to generate code to run in the ISR. I also said that performance of code from that compiler would NECESSARILY be awful, and would be incompatible with the C code written to run in the ABI the machine was designed to run.

Don't feed the trolls 

[djacobow]

No, it was written by a normal person who is not accustomed to dealing with Internet trolls who live to nitpick the finest details.

I should have said "it is entirely impractical, inefficient, and pointless to write ISRs above a certain priority level in C."

There are lots of smart people on this board who know all sorts of interesting things. I don't know that much about boards, analog electronics, and a zillion other things, but it just so happens I am have designed major portions of several very common microprocessors and am an expert in microprocessor and computer architecture. You actually had an opportunity to have an interesting discussion about microprocessors, ISA design, microarchitecture, ABIs, "C" linkage, etc, and all the interesting trade-offs that can be made regarding design complexity, performance, code size, latency, "compiler friendliness," and a zillion other things.

Instead, you chose to turn this thread into an inquisition for your own childish pleasure.

I said a C compiler could be written to generate code to run in the ISR. I also said that performance of code from that compiler would NECESSARILY be awful,

Before you get too far, here is exactly what you said:

- our architecture had an unfortunate quirk in that ISRs attached to interrupts above a certain priority level could not be written in C;

That's some "gymnastics" to reconcile the two.

[dannyf]

I should have said

I shouldn't have wasted my time here,

I am have designed major portions of several very common microprocessors and am an expert in microprocessor and computer architecture.

"I am have"?

I am have designed the universe,

You actually had an opportunity to have an interesting discussion about microprocessors, ...

Yeah, right.

[dannyf]

I should have said "it is entirely impractical, inefficient, and pointless to write ISRs above a certain priority level in C."

I don't know why priority has anything to do with doing it in a particular language. I can understand that above certain performance requirement, doing it in C could potentially be an issue - even that is compiler / programmer dependent.

But the same can be said about any language (including assembly) or any way of doing things. ie. there does not exist one approach that will always be practical, efficient or "un-pointless" above certain performance threshold.

[retrolefty]

        

[WarSim]

Good grief two pages later and the personal attacks continue.  Will the thread returning to the topic anytime soon?


Sent from my iPad using Tapatalk

[djacobow]

I'm sorry, guys. My original comment was that, from experience guiding a lot of people through a certain kind of embedded project (writing software to run in new custom ASICs incorporating one or more microprocessors) was that SW folks did not typically come "ready" to do good embedded work, and that a lot of details and problems of embedded systems were new to them. However, I can't remember running into a software person who could not become productive in such work after a period of introduction.

So, in essence, my answer to "who should write embedded software" is basically anybody interested in it enough to deal with learning curve, willing to deal with targets with limited observability, tools that are not quite up to the level they're used to, etc. EEs may have some advantages, particularly bringing up unknown and unstable hardware, and SWEs have maybe an advantage managing the complexity of a large app, but overall success seemed to be about building up a toolbox of how to deal with what is often a very "raw" software environment, which anyone clever can do.

Good grief two pages later and the personal attacks continue.  Will the thread returning to the topic anytime soon?

[WarSim]

I'm sorry, guys. My original comment was that, from experience guiding a lot of people through a certain kind of embedded project (writing software to run in new custom ASICs incorporating one or more microprocessors) was that SW folks did not typically come "ready" to do good embedded work, and that a lot of details and problems of embedded systems were new to them. However, I can't remember running into a software person who could not become productive in such work after a period of introduction.

So, in essence, my answer to "who should write embedded software" is basically anybody interested in it enough to deal with learning curve, willing to deal with targets with limited observability, tools that are not quite up to the level they're used to, etc. EEs may have some advantages, particularly bringing up unknown and unstable hardware, and SWEs have maybe an advantage managing the complexity of a large app, but overall success seemed to be about building up a toolbox of how to deal with what is often a very "raw" software environment, which anyone clever can do.

Good grief two pages later and the personal attacks continue.  Will the thread returning to the topic anytime soon?

Now that is a good answer I can agree with. 


Sent from my iPad using Tapatalk

[vvanders]

Two cores is difficult enough. Or even an (RT)OS with two collaborating tasks.
But try vhdl, everything happens in parallel. Then you won't complain anymore.

- on-chip peripherals were a mystery to most unless wrapped by someone else in friendly functions
- our architecture had an unfortunate quirk in that ISRs attached to interrupts above a certain priority level could not be written in C; They had to be in assembler, and you had to save and restore the registers you intended to clobber. This in theory was no great hardship, because usually with high priority interrupts, you wanted to get in and get out quickly, doing something simple. But the howls, HOWLS from developers about this limitation were endless
- SW folks did not like funky memory maps, disjoint memory spaces (like DSP "X/Y" memories) and other hardware tricks that segmented their view of the world.
- SW folks had a really hard time wrapping their heads around the idea that the hardware they were targeting might be buggy.

@djacobow, Visual Studio and php people are not supposed to do the low level embedded software.
You must know how your C(++) compiles to machine code.
Test is simple, if they think Java or Microsoft Java ^C# are good candidates for low level embedded software, you find someone else.

Don't mistake the tool for the engineer, as mentioned Ateml is using the Visual Studio shell. It's also very straightforward to use VS with makefiles to do embedded work. At the risk of starting another religious war I find it to be one of the best IDEs on the market.

Also, while I agree that Java and C# have no place in performance critical code they are still extremely valuable languages. I challenge anyone to find a language that's more productive for building UI than C# and with C++/CLI you have an extremely seamless access to native code interop. There's many support parts of building embedded systems where tools like these can be extremely valuable.