On Fri, Dec 05, 2003 at 04:39:59PM -0800, Jonathan Kirwan wrote:
> Just curious, and it's probably
"unspecified" behavior in C, but
> what happens when you cast a char* to an int* and then use it?

Using a cast on a pointer is telling the compiler "I know what
I'm doing here". If you're wrong, and you don't know what
you're doing, that's your problem.

Without looking it up, I can't be sure, but I would expect that
falls into "undefined behaviour" as far as the standard
is concerned. As to what compilers actually do, I would expect
the cast to NOT change the value of the pointer. Rounding it
to an even value might be acceptable under a strict
interpretation of the standard, but it wouldn't be very useful
and would certainly be unexpected by most users. So why do it?

> It would be interesting to see if there could be a
valid
> combination of union and struct which could cause problems,
> while at the same time having _specified_ behavior under the C
> standards.  Nothing comes immediately to mind, though.

I'm not sure what you mean. The only difference between a struct
and a union is that all members of a union have offset 0. A union
on e.g. the 430 will still get padded to an even number of bytes.
For example this union:

union {
       int 	a;
       char     b[3];
};

MUST be padded to have a size of 4, on a chip that does not allow
word accesses on odd boundaries.

The reason why is left as an exercise to the reader.....

Clyde

-- 
Clyde Stubbs                     |            HI-TECH Software
Email: clyde@clyd...          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger clyde@clyd...   | AUS: +61 7 3552 7777 +61 7 3552 7778
---
HI-TECH C: compiling the real world.

Hey Kris, why would I start a war over this. I've always made it clear

(I hope) that my almost total use of asm is related more to the type of 
projects I tend to do, and the way I tend to do them, than it is a 
'religious' belief. If I came across a job that was nice and simple, 
with no critical timing issues, or no critical size issues, or no 
critical power consumption issues, and it didn't readily fit my off the 
shelf libraries I'd use C. In fact I've got one. Oddly enough it was 
proptotyped in asm, as I had all the modules for evaluation available 
(mainly some monochrome graphics and an SPI core), but it will later be 
performing a lot of string processing, something I don't have libraries 
for, so I'll use it as a good excuse to finally evaluate a couple of 
compilers. I C no point in doign this all in asm as I don't expect to do 
lots of string handling in the future.

Cheers

Al

microbit wrote:

> Al wrote :
> 
> 
>>ASM makes life easy in these circumstances, I do it all the time, mixing
>>types, and taking advantage of the ability to do this. Could you not
>>handle these difficult areas in asm?
> 
> 
> Hi Al,
> 
> Ouch !
> There comes the dreaded thorn.
> 
> Strangely, no, not in _my_ particular application because I'm already
> "breaching"
> ISO anyway, by giving a char array datatypes that are larger (int, long,
> float), thus
> I'm left high and dry.
> But there is simply __no other__ way around it given the byte-based token
> scheme.
> Storing 16/32 bits anywhere in MSP430 memory incurs this problem.
> 
> ASM will not help, *maybe* if it is painstakingly optimised to run faster
> with 8 bit operations
> than the C 16-bit LIB code (which will run much faster anyway, and is also
> ASM hand written)
> 
> BUT, I'll go on a limb here, and volunteer that in fact the whole
project
> would be
> slightly more RAM efficient in ASM, but it was specifically intended to be
> very portable.
> (where actually 60% of the work was :-)
> It must be stressed though that is a very _unusual_ exception.
> (the RAM savings are only 30-40 bytes though !)
> 
> So, basically this is finally "the exception to the rule", and in
fact I
> will admit that if
> you started the full scope of the task in ASM while I started in C,
> you'd probably finish it 3 times faster than me !!
> ___BUT___ after that it will take me 30 seconds to land it on any 8 bit
MCU,
> it will take
> you much longer than that on a new MCU ....
> 
> I hope I haven't started up another Pandora's box, but actually
have closed
> one
> vis-a-vis ASM vs. C ....
> But I'm forthcoming too, and will grant you your _salient_ point Al
!!!
> 
> Best regards,
> Kris
> 
> 
> 
> .
> 
>  
> 
> ">http://docs.yahoo.com/info/terms/ 
> 
> 
> 

Great to see we agree on this one Al.
As I said recently, it's taste and it is *acquired*.
At some stage I'll be trying the suggestions people offered about Lint,
but I guess we engineers tend to be a bit inert to change ("don't muck
with it" :-))

Although I'm glad Paul's implied view seemed to be (at least, that was
how I 
interpreted it) mine, that these can be "props". 
IOW some sort of sense a false security... (to me), so... dunno !
But I can clearly see how you would perceive a whole C toolchain the way
I had perceived "code writing checkers".

Reminds me of a large network that someone installed at Ardmona fruit many years
ago.
The task of double checking the CRC function firmware on an access control
network
put in there was never done, and people found themselves merrily walking into
areas
of the building they weren't supposed tyo have access to for quite some
time before the
bug was found !!!

I think that says it all, and it's quite funny really.....

-- Kris




----- Original Message ----- 
From: "onestone" <onestone@ones...>
To: <msp430@msp4...>
Sent: Saturday, December 06, 2003 1:51 PM
Subject: Re: Is now word alignment, was Re: [msp430] C language tools to use
with MSP430 or ...


> Hey Kris, why would I start a war over this.
I've always made it clear 
> (I hope) that my almost total use of asm is related more to the type of 
> projects I tend to do, and the way I tend to do them, than it is a 
> 'religious' belief. If I came across a job that was nice and
simple, 
> with no critical timing issues, or no critical size issues, or no 
> critical power consumption issues, and it didn't readily fit my off
the 
> shelf libraries I'd use C. In fact I've got one. Oddly enough it
was 
> proptotyped in asm, as I had all the modules for evaluation available 
> (mainly some monochrome graphics and an SPI core), but it will later be 
> performing a lot of string processing, something I don't have
libraries 
> for, so I'll use it as a good excuse to finally evaluate a couple of 
> compilers. I C no point in doign this all in asm as I don't expect to
do 
> lots of string handling in the future.
> 
> Cheers
> 
> Al

Paul,

> That's an assertion that I find hard to
swallow because you have so
> little data to back up the claim.  I think your %hu/%u problem is a
> configuration problem, not an ANSI compliance problem.  In micro land,
> we often need to ditch the baggage of the ISO standard because if we
> included everything in the library to achieve compliance for all
> applications, then we'd run out of room on our devices.

From a high price compiler i do expect that i can use the ANSI-C-Code with the
conversion specifier u.
If the compiler can't  compile the ANSI-C-Code i do expect an error message
and not a silent bug!
That wouldn't be a real problem if the incompatiblities are reported (as
errors/warnings) but it's much work to
find out that things like the conversion specifier u and sscanf does not work
with icc430. And it's extra work to
do workarounds around these bugs.
With these icc430-bugs things like reading out the build time and build date
(from __DATE__ and __TIME__) are very
hard although it is easy with an ANSI-C-Compiler like gcc/mspgcc.

The icc430 is not the only bad thing from IAR, because the C-SPY also has some
big bugs like RS232 communication even with UART0 does not work if one ore more
breakpoints are set. My colleagues have tried several baud rates but they
also did not found a workaround for that bug.

Rolf F.

Hi,

i don't think that you have to pay something if you don't want to by a

licence from MS because a) FAT is from 1976 and a patent has a lifetime 
of max. 21 years and b) a storage format (and nothing else) is so simple 
that it can't be patented (in EU, but in USA you can get a patent for 
every bullshit).
For private use it's no problem because patent rights do only affect 
commercial users.

Rolf F.

Matthew Cook schrieb:
> Seems Micro$oft is on the money grab again
> 
> http://www.microsoft.com/mscorp/ip/tech/fat.asp
> 
> It seems they want to now start charging for use of their FAT file system.
> 
> Not good news...
> 
> Matthew
> 
> 
> *
>
<http://www.netflix.com/Default?mqso`178356&partidA16732>" target="_blank" rel="nofollow">http://rd.yahoo.com/SIGcmsdrqp/M&7637.4116732.5333197.1261774/D=egroupweb/S05005378:HM/EXP70753019/A53619/R=0/*http://www.netflix.com/Default?mqso`178356&partidA16732>
> 
> 
> .
> 
> 
> 
> ">http://docs.yahoo.com/info/terms/>.

Rolf,

> Paul,
> 
> > That's an assertion that I find hard to swallow because you have
so 
> > little data to back up the claim.  I think your %hu/%u problem is a 
> > configuration problem, not an ANSI compliance problem.  In 
> micro land, 
> > we often need to ditch the baggage of the ISO standard 
> because if we 
> > included everything in the library to achieve compliance for all 
> > applications, then we'd run out of room on our devices.
> 
> From a high price compiler i do expect that i can use the 
> ANSI-C-Code with the conversion specifier u. 

You can.  I've tried it with the medium formatter.  The capability of
each formatter is documented by IAR.

> If the compiler 
> can't  compile the ANSI-C-Code i do expect an error message 
> and not a silent bug! That wouldn't be a real problem if the 
> incompatiblities are reported (as errors/warnings) but it's 
> much work to find out that things like the conversion 
> specifier u and sscanf does not work with icc430. And it's 
> extra work to do workarounds around these bugs. With these 
> icc430-bugs things like reading out the build time and build 
> date (from __DATE__ and __TIME__) are very hard although it 
> is easy with an ANSI-C-Compiler like gcc/mspgcc.

It's not possible to check at compile time that a format string is
"supported".  Having said that, it should be qualified: actually, it
is
possible if the format string is a string constant *and* you know what
formatter you're using.  Formatter selection is left to link time,
however, so the compiler can't check all possibilities.  The Codemist
compiler checks format strings at compile time; for all I know, the GNU
one might too, but I don't use it.

> The icc430 is not the only bad thing from IAR,
because the 
> C-SPY also has some big bugs like RS232 communication even 
> with UART0 does not work if one ore more breakpoints are set. 
> My colleagues have tried several baud rates but they also did 
> not found a workaround for that bug.

Have you checked that you're keeping the clock to the peripheral
running?  Many MSP430 devices have module and general clock control and
if you stop the clocks when a breakpoint is hit then the peripherals
stop (or not) depending upon the debugger settings.  CrossWorks allows
you to set the options for general and module clock control, I'm not an
expert on EW430 so can't say whether this is implemented by IAR.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430 and ARM processors 

The FAT32 & long filename patent is more recent.  I can see that if
something other than plain old FAT is used then you might fall foul of
FAT32 patents.

My personal opinion is that MS are doing themselves a big dis-service in
this area.  I think they've seen the money making opportunities or, more
cynically still, believe that the one-time-payable license fee option
will stop competition with their media ambitions.

I have an Orange SPV smart phone and, to be honest, its MP3/WMA playing
performance is complete s**t.  It stops playing when the phone is
"busy"
doing something, like moving between cells for all I know.  I wouldn't
recommend an SPV to anybody, I'm on my third after software
replacements...

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430 and ARM processors 

> -----Original Message-----
> From: r f [mailto:nobodyo@nobo...] 
> Sent: 06 December 2003 11:48
> To: msp430@msp4...
> Subject: Re: [msp430] Fat File Systems
> 
> 
> Hi,
> 
> i don't think that you have to pay something if you don't 
> want to by a 
> licence from MS because a) FAT is from 1976 and a patent has 
> a lifetime 
> of max. 21 years and b) a storage format (and nothing else) 
> is so simple 
> that it can't be patented (in EU, but in USA you can get a patent for 
> every bullshit).
> For private use it's no problem because patent rights do only affect 
> commercial users.
> 
> Rolf F.
> 
> Matthew Cook schrieb:
> > Seems Micro$oft is on the money grab again
> > 
> > http://www.microsoft.com/mscorp/ip/tech/fat.asp
> > 
> > It seems they want to now start charging for use of their FAT file 
> > system.
> > 
> > Not good news...
> > 
> > Matthew
> > 
> > 
> > * 
> > 
> <http://rd.yahoo.com/SIGcmsdrqp/M=>
267637.4116732.5333197.1261774/D> > 
>
egroupweb/S05005378:HM/EXP70753019/A53619/R=0/*http://www.net
> > flix.com/Default?mqso`178356&partidA16732>
> > 
> > 
> > .
> > 
> > 
> > 
> > ">http://docs.yahoo.com/info/terms/>.
> 
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> ---------------------~-->
> Buy Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark
> Printer at MyInks.com. Free s/h on orders $50 or more to the 
> US & Canada.
> http://www.c1tracking.com/l.asp?cidU11
> http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/CFFolB/TM
> --------------------------
> -------~->
> 
> .
> 
>  
> 
> ">http://docs.yahoo.com/info/terms/ 
> 
> 
> 

Hi,

>  > From a high price compiler i do expect that
i can use the
>  > ANSI-C-Code with the conversion specifier u.
> 
> You can.  I've tried it with the medium formatter.  The capability of
> each formatter is documented by IAR.

i and my colleagues could reproduce the error with writing via spi on a 
MMC. Because the bug is gone when only u is changed to d the bug is in 
sprintf. Maybe the 2.x version of icc430 does not have this bug but the 
1.26 version does have this bug!


> > With these
>  > icc430-bugs things like reading out the build time and build
>  > date (from __DATE__ and __TIME__) are very hard although it
>  > is easy with an ANSI-C-Compiler like gcc/mspgcc.
> 
> It's not possible to check at compile time that a format string is
> "supported". 

That's wrong because __DATE__ and __TIME__ are CONSTANT strings produced 
from the preprocesser. Because the compiler is started after the 
preprocessor it's trivial to check that these constant strings are 
supported!
By the way: Is there any way to se the preprocessed code with the IAR IDE?

Rolf F.

On Sat, 6 Dec 2003 12:17:35 +1000, you wrote:

>On Fri, Dec 05, 2003 at 04:39:59PM -0800, Jonathan
Kirwan wrote:
>> Just curious, and it's probably "unspecified" behavior
in C, but
>> what happens when you cast a char* to an int* and then use it?
>
>Using a cast on a pointer is telling the compiler "I know what
>I'm doing here". If you're wrong, and you don't know
what
>you're doing, that's your problem.

hehe.  Never disagreed with that!  And it would be ridiculous to
expect the compiler to generate more generalized code in cases
where it could not logically guarantee .even alignments when it
otherwise needed them.

>Without looking it up, I can't be sure, but I
would expect that
>falls into "undefined behaviour" as far as the standard
>is concerned. As to what compilers actually do, I would expect
>the cast to NOT change the value of the pointer. Rounding it
>to an even value might be acceptable under a strict
>interpretation of the standard, but it wouldn't be very useful
>and would certainly be unexpected by most users. So why do it?

Agreed!!

I suppose this is an opportunity for the compiler to point out
the dangers of casting a (void*) or (char*) to a .even aligned
type of pointer... as a warning if the warning level is set high
enough.  Casts from (void*) to (char*) and (any*) to (void*)
might be considered safer, though?

>> It would be interesting to see if there could
be a valid
>> combination of union and struct which could cause problems,
>> while at the same time having _specified_ behavior under the C
>> standards.  Nothing comes immediately to mind, though.
>
>I'm not sure what you mean. The only difference between a struct
>and a union is that all members of a union have offset 0.

Within the union, yes.  Placed as an element in a struct the
union may have a different offset.  And the union may, itself,
be a union of structs, which have various combinations of
members.  But again, I'm sure that compilers are smart enough to
associate a .even alignment with a union which may require word
access for any of its elements and to promote that alignment
requirement to any 'padding logic' should that union itself be a
member of a struct, for example.

>A union
>on e.g. the 430 will still get padded to an even number of bytes.
>For example this union:
>
>union {
>       int 	a;
>       char     b[3];
>};
>
>MUST be padded to have a size of 4, on a chip that does not allow
>word accesses on odd boundaries.

Well, just to be slightly argumentative here, would it be
possible that a C compiler could implement that union as 5 bytes
in cases where the object was a scalar, just so long as the
instance is always guaranteed to be .even aligned (which the
compiler can guarantee, given appropriate communication with the
linker about static instances, and the implicit .even
requirement for stack elements on the MSP430?  It seems that in
cases of arrays of that union, a pad byte would be required.
But if the extra pad byte in the case of the array is placed at
the end where I'd expect it to be, runtime code operating on
instances in the array wouldn't know or care about the extra pad
byte, I'd imagine.  Just a thought.

...

I honestly didn't know what I was talking about, either.  Just
hand-waving in a general (and probably fruitless) direction.  I
was curious if there were any "corner cases" where behavior _is_
specified in the C standard and where, in cases like the MSP430,
it's possible to get "caught between a rock and a hard place."
I don't think so, because I believe that word alignment issues
have been with us long enough before the standard was written,
and on machines explicitly targeted by C, that any such problems
have long ago been vetted.

But I was still curious if those in the business were aware of
some remaining "problem areas," here.

What's interesting about this subject with the MSP430 is what
Kris was talking about.  When you are writing C code which must
pack and unpack data streams between itself and the "outside
world," it's easy to imagine variable-length fields contained
within the stream of data which must be extracted.  This might
apply when processing a compiler object file (unlikely, in an
embedded application) which often use packed, variable-length
fields.  It might also apply in processing network packets and
datagrams, which is far more likely I suppose in some embedded
applications.

Since the format of the stream is not within control of the C
program, the elements within it may not necessarily obey
alignment restrictions while they remain packed in a buffer.
There may be a very strong temptation to examine, at a minimum,
certain key fields in each variable length record and to do so
"in place" without copying the record out, byte by byte, to a
properly aligned structure.  But, as is easy to understand in
the case of a processor which simply cannot perform word reads
aligned on odd-byte addresses, simply casting a (void*) or
(char*) pointer to the desired structure type pointer isn't
guaranteed to be portable.

It seems that any given C code which tries to be highly portable
across platforms may also be simultaneously highly non-optimal
in certain circumstances.  Having to perform byte by byte copies
of elements just to properly check key fields could have a
serious impact on performance in some cases.  More so, in fact,
than if the compiler had generated two one-byte instructions to
load the value through the pointer, instead.

Perhaps there are times when it would be nice to just tell the
compiler that "this structure is packed exactly _this way_ and I
want you to generate code which will work regardless of its
alignment, should I ask you to access elements via this
structure or a pointer to it."  And then just leave it to the
compiler tool vendor to worry out the details for a specific
target.

>The reason why is left as an exercise to the
reader.....
>
>Clyde

Or an exercise for the compiler vendor?  I mean, you folks *are*
a cut above the rest, right?

Speaking of which, I want a C compiler with syntax to support
iterator style coroutines, as in CLU.  Only one stack is used in
this case, so nothing fancy there.  But very sweet to use.

Jon

On Mon, 08 Dec 2003 00:43:53 -0800, I wrote:

><big snip>
>Speaking of which, I want a C compiler with syntax to support
>iterator style coroutines, as in CLU.  Only one stack is used in
>this case, so nothing fancy there.  But very sweet to use.

I've been contantly on alert for such helpful semantics in
compilers, by the way, for 20 years and more.  Metaware took the
bold step of including them in their Pascal and C compilers
(which I have.)  [If only they could keep their biblical quotes
out of the manuals.  But deRemer wanted them in.]

Anyway, I'm not the only one lauding them.  It appears that even
the infamous Microsoft is now pusing the idea in .NET.  Here:

http://msdn.microsoft.com/msdnmag/issues/03/09/CoroutinesinNET/default.aspx

So get on the ball and give me what I want!!  ;)

Jon