TI's Code Composer does not clear bss data

Jon Kirwan wrote:
> On Fri, 28 Jan 2011 19:54:56 +0000 (UTC), Grant Edwards

>> The MSP430 would feel very
>> familiar to anybody who had worked with a PDP-11.
> 
> About like a staple-gunned, sawdust-board knock-off bookshelf
> reminds me of one decently designed and fabricated from
> select Cherry pieces that the cheap version was intended to
> mimic.  It's when you put hands on the two that you know
> which is much better than the other.
> 
> Jon
>

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...

Regards,

Chris

Hans-Bernhard Br�ker wrote:

> 
> Compilers that don't fulfill even the most basic aspects of this 
> contract aren't worth the space they take up on the disk even at todays 
> rather modest costs for that commodity.

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 :-).

> 
>> I do this from habit, even when I know that it has been cleared via
>> the setup asm code. It's so little added effort and makes the intent
>> clearer on the page...
> 
> And while at it, it wastes code space.  If you're never in a situation 
> where that might risk breaking your entire project, consider yourself 
> lucky --- or young.

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...

Regards,

Chris

On 30.1.11 6:06 , ChrisQ wrote:

> 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.


The basic PDP-11 had 64 kbytes of addresses, of which 8 kbytes at the
end were reserved for I/O. What's the difference?

-- 

Tauno Voipio

Tauno Voipio wrote:
> On 30.1.11 6:06 , ChrisQ wrote:
> 
>> 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.
> 
> 
> The basic PDP-11 had 64 kbytes of addresses, of which 8 kbytes at the
>  end were reserved for I/O. What's the difference?
> 

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...

Regards,

Chris

On 30.01.2011 17:48, ChrisQ wrote:
> Hans-Bernhard Br�ker wrote:

>> And while at it, it wastes code space. If you're never in a situation
>> where that might risk breaking your entire project, consider yourself
>> lucky --- or young.

> One could argue that if the project is that tight on code space, then
> you chose the wrong device.

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.

> Compared to earlier designs, modern devices have a glorious abundance
> of resources

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.

> and most vendors offer the same device / pinout with various amounts
> of flash and ram. Such a thing should never become an issue...

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.

On Sun, 30 Jan 2011 16:48:57 +0000, ChrisQ wrote:

>> Compilers that don't fulfill even the most basic aspects of this
>> contract aren't worth the space they take up on the disk even at todays
>> rather modest costs for that commodity.
> 
> 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.

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'

On 30.1.11 7:44 , ChrisQ wrote:
> Tauno Voipio wrote:
>> On 30.1.11 6:06 , ChrisQ wrote:
>>
>>> 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.
>>
>>
>> The basic PDP-11 had 64 kbytes of addresses, of which 8 kbytes at the
>> end were reserved for I/O. What's the difference?
>>
>
> 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...

You'll get Cortexes from TI with 32 bit registers and addresses up to
32 bits from TI. I guess thet the time for a long-address 430 is over.

It is plenty easier to handle the addresses over 16 bits with a core
with long enough registers.

Besides, small Cortexes are pretty fast with little power and they
cost just a couple of monetary units (dollars, sterling, Euros etc).

-- 

Tauno Voipio

Arlet Ottens wrote:

> 
> 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" ?
> 
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.

> 
> 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'
> 

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 :-)...

Regards,

Chris

On Sun, 30 Jan 2011 19:50:59 +0000, ChrisQ wrote:

>> 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" ?
>> 
> 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.

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. 

> 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 :-)...

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.

Tauno Voipio wrote:

> 
> You'll get Cortexes from TI with 32 bit registers and addresses up to
> 32 bits from TI. I guess thet the time for a long-address 430 is over.
> 
> It is plenty easier to handle the addresses over 16 bits with a core
> with long enough registers.
> 
> Besides, small Cortexes are pretty fast with little power and they
> cost just a couple of monetary units (dollars, sterling, Euros etc).
> 
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 (<$20 each) eval boards on the 
bench. The stm32F... are tiny packages and a couple of the pins were 
solder bridged on arrival, but no matter and now fixed. Build quality 
otherwise well up to standard. Am probably very late to the Cortex party 
but it looks like Arm have finally come of age. In particular, the 
integration of the interrupt controller and proper vector table, 
interrupt mask and pending register had me thinking more of 68k and 
dragonball, both well respected architectures around here. (Of course, 
pdp11 had a fully vectored interrupt architecture from the first model 
in 1969 :-).

Much more work to do, but a couple of other things. The stm32F series 
has an external memory interface which should make it easy to drive 
memory or mapped lcd controller devices. Both also have fancy dma modes, 
but the nxp series also has a scatter gather dma mode via linked lists 
in memory, which could be very usefull in optimising io bandwidth. 
Together with the low end 1100 nxp series, they could replace just about 
all applications here, including 8 bit. They are relatively cheap as 
well. Time will tell, but nothing else seems to get close in capability 
at present.

What do you think and have you done any work with Cortex ?...

Regards,

Chris