msp430 is about as close as you can get to pdp11 architecture, without actually having one, but the limited address space and lack of external address bus limits it's application. Perhaps later versions have addressed this.
I remember using Whitesmiths C for pdp11. In fact a cross compiler from dos to pdp11, around 1985/86. Still have the floppies and ringbinder somewhere as well. Seem to remember that the code it produced was not that special, though in historical context, c compiler quality wasn't that good in general, didn't comply to any particular standard (were there any ?) and one was gratefull sometimes just to have the compiler produce bug free code. Nothing like as good as hand written and optimised assembler. For those one came from an assembler background and who were quite rightl suspicious of early c tools, the assumption was that the only way to get reliable code was to look at the output and write everything yourself, even if there were libraries and startup code examples.
Perhaps we are all spoilt now, with everything done in C and the ide taking care of the rest, but it perhaps leads to a false sense of security and overly high expectations...
Complete agreement, but perhaps my expectations are lower, in that all I expect from a complier is that it should translate the source consistently, reliably and efficiently. Anything else is a bonus. Of course, the distinction between the various responsibilities can become blurred once the compiler, asm, linker etc are encapsulated and hidden within an ide.
All tools have limitations and after a while, you just have to work round, get over it, move on and get the job done :-).
One could argue that if the project is that tight on code space, then you chose the wrong device. Compared to earlier designs, modern devices have a glorious abundance of resources and most vendors offer the same device / pinout with various amounts of flash and ram. Such a thing should never become an issue...
Agreed, but the later pdp11's had first 18 and then 22 bits of address, or 4 Mbytes of address space, which would be quite respectable for embedded work even by modern standards. Ok, it needed the 8k page memory management unit to access the whole address space, but they also also had separate i and d spaces, which allowed a basic 128 kbytes access.
An msp430 with q22 like extensions and an external address bus to allow access to things like graphic lcd controllers would make it more usefull, but i'm afraid they have been overtaken now by more modern designs.
It's a pity TI didn't invest more resources into development, as the msp had one of the most elegant new architectures around when it was introduced...
If only it were that simple. More often than not, it's not us engineers that get to choose. One has to consider himself lucky if purchasing / marketing so much as asks before they choose. And even then odds are suspiciously hight they'll happily ignore the answer, anyway.
Easier to have the software department burn 1000+ hours on somehow squeezing the software into a device decreed un-upgradeable, than for purchasing to admit (by revising their cost projection) that they failed to listen to what engineering told them from the get-go. And mind you: that's what they do on a comparatively high-price, low-volume product for this shop. You should see the lengths they're prepared to go to if something like that happens to a million-seller.
And modern customers have _way_ more complicated expectations than they used to, back in the day. One of our products has 8 times as much ROM as its predecessor did, and yet we ended up having to squeeze real hard to get all the customer's requirements fulfilled in such limited space.
Oh believe me, it is an issue. It's a rock-hard issue once you reach the upper end of that selection, where they simply don't have any variant with even more ROM. It's an almost equally hard issue if marketing can't muster the courage to charge the extra cost of the bigger device to the customer, even after said customer knowingly ignored their own rules regarding required free memory at various stages of development.
Translating the source reliably also includes clearing the BSS during start up. If you can't depend on the tool chain to translate "int a" correctly, why would you assume it does any better on "int a = 0" ?
Until proven/stated otherwise, I will assume the tool chain adheres to all the standards. If it doesn't do that, I'll find out soon enough.
And for those case where the tool chain doesn't clear the BSS properly, I would just fix the start up code myself, rather than explicitly initializing my variables with '0'
The problem in the latter case is that the compiler has no implicit awareness of the startup code that initialises int a = 0;, other than reserving symbol table space and context for a. For a static / global var outside function scope, the init is implied by including the startup code at link time. ie: The compiler can't emit code to initialise a, whereas int a = 0; within function scope will result in code to initialise it on function entry.
Ime, you always end up having to modify the example startup code, add to it, or completely rewrite for a project. I don't think it's ever intended to be set in stone, even parts are mandatory for ansi compliance :-)...
I see. You want to explicitly initialize all variables in function code. I thought you were talking about adding an explicit '= val;' initializer to static variables. Actually generating initialization code seems like a waste, and also makes the code less readable, and harder to maintain. If you have reason to doubt the correctness of the tool chain, it's easier to do a code inspection of the start up code before using it.
It varies. I would guess that in at least half of my projects, the default start up code works just fine... and I've never had any experience of BSS/DATA segments not being initialized correctly.
Interesting that you should mention Cortex. As part of the year end break project, have been looking at the st stm32... and nxp Cortex series and have a couple of Ebay Chinese (
There was an accident - the 10 years old production documents of an AT91 ARM7TDMI -based intelligent sensor card got destroyed, and the customers want a replacement.
Our team had to create something fast, and we eneded up with a LM3S818 Cortex-M chip. Porting the old code to the new processor was done in two weeks and as a surprise to everybody, it worked. The toolkit in use is the GNU Compiler suite (GCC + GDB and binutils) for both targets. The most complicated thing in the porting was to change the multi- thread kernel for the newer interrupt and thread switching hardware mechanisms.
The Cortex-M is surprisingly fast, especially for handling interrupts and thread switches.
A compiler is part of a toolchain, which includes the assembler, linker, and (at least) basic standard libraries. The compiler should be able to assume that these tools work according to the standards for the given target, host, object file format and language. The compiler /does/ have an awareness of the startup that initialises data put in different sections - it knows that it can put them in specific sections for specific defined results. Of course, the compiler, assembler, linker and library don't have to use the popular ".bss" and ".data" sections - but if not, then they must have an alternative method of achieving the same effect.
The C standards say that the file-scope statement "int a;", or "static int a", will result in the variable "a" being initialised to arithmetic
The compiler knows that's what you expect, and it is responsible for ensuring (in cooperation with the linker and library) that this is what you get.
When the toolchain falls over at the first hurdle - the C run-time environment initialisation - I see no reason to assume that it does any better at anything else.
It is more accurate to describe the CCS toolchain as being broken rather than the compiler, since the fault is in the combination.
Without getting into niggling issues such as binary object code compatibility (which doesn't matter to me) or source code compatibility for the assembler (which also doesn't matter to me), I see no reason at all why the instruction set designer failed to learn as well as should have been done, from what had already gone before.
What isn't acceptable is to take wrong turns into dead ends when others have already surveyed the territory, examined those dead ends, and beaten down the right path for you for a much more successful path.
The design of the PDP-11 is very good, but I've still no doubt at all that a clever designer may be able to do still better. Especially in a modern context that the old PDP-11 designers couldn't have anticipated. And I'd bow deeply to such a successful effort.
But *this* designer made needlessly stupid mistakes. And to a German, that statement stings.
The MSP430 (even before it was so named) possessed a 16-bit register size and a 16-bit address bus, so far as I'm aware. Same with the PDP-11. Newer versions of the PDP-11 had to deal with an expanding physical address bus width, and they chose one route. The MSP430 also had to deal with expanding physical address bus width and later incarnatins dealt with that need somewhat differently.
A huge advantage to modern designs is the ability to integrate so much into a single IC and this applies to the MSP430. It is not a problem when ICs include large memories within an IC package, don't include all the extra pins (which are, in many cases, the pricing driver) for an external address bus. Lower pricing, easier board design and stuffing costs, easier prototyping, etc., are pretty nice things to have. Had it been possible in the PDP-11 days, I'm sure it would have champed at the bit for such an opportunity to reduce all that external hardware and attending problems.
The absolutely wonderful thing today is that there are so many options, even in this difficult economy period. One can buy in singles, or hundreds, or hundreds of thousands. One can buy SOT-23, DIP8, SOIC 44, or a 288-BGA. External bus or none. 8-bit ALU, 16-bit ALU, 32-bit ALU.... Hardware multipliers, hardware dividers, floating point (or not), etc.
There are so many choices that in many cases there is more than one GOOD choice and one can instead choose based upon the kind of partner they are looking for.
It's not a problem to lack an external bus. It's a matter of targeting.
None that I've used. But I'm not keeping up to date on all the MSP430s coming out, either.
I've had that experience.... but it's always because I *have* modified the startup code and messed it up :)
Very often one has to initialise clocking, SDRAM etc before the C runtime. Rather than write this in assembler, I usually use C but without relying on statically initialised variables.
(But I agree with David that outside of these special circumstances it is counterproductive to always second-guess the compuler and "manually" initialise these.)
Yes, there are times when you need special code - but it should be special cases. Toolchains which target devices where this sort of thing is common often have hooks or special sections of some sort to make it easy to add board-specific startup code before standard C startup code, or to replace the standard C startup code.
I too have written my own startup code for SDRAM setup using pre-runtime C code. You have to be a little careful to avoid things like stack usage if you haven't set that up yet, but it's quite possible to do this without anything more than a couple of inline assembly statements.
I still have a look at the TI msp pages from time to time, but I think you are right in that TI never saw it as a long term expandable architecture. Otherwise, why would they effectively sit on it for ten years while the rest of the world moved on ?. I guess in the end, a gp
16 bit register set doesn't translate well to > 16 bits worth of address space, however it's done...
Two weeks :-) - Illustrates better than anything how the use of near common architectures can save time, not to mention the benefit in terms of software reuse.
Have you got the Joseph Yiu book on the M3 ?. Bought a copy on abe over the holiday and it's full of usefull info, code examples etc. Fills in most of the gaps in the data sheets and mfr code...
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.