HC08: Confusing CW manual

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

HC08: Confusing CW manual

Jump to solution
2,040 Views
bigmac
Specialist III
Hello all,
 
I have recently been reading (perhaps belatedly) the Compiler manual for CW08 V5.0.  I have come across a couple of areas I am not particularly happy with, and find somewhat confusing.
 
The following paragraph can be found within section 9, "Generating Compact Code" -
Unsigned Data Types
Using unsigned data types is acceptable as signed operations are much more complex than unsigned ones (e.g., shifts, divisions and bitfield operations). But it is a bad idea to use unsigned types just because a value is always larger or equal to zero, and because the type can hold a larger positive number.
The author does not say why it is considered a "bad idea". I might have considered the use of unsigned data types a very good idea if it results in simpler and more compact code, and avoids the need to use an int variable in place of char, or a long in place of int.  What could be the perceived problem with using unsigned data types?
 
However, I am more generally unhappy with the whole of section 11, "High-Level Inline Assembler for the Freescale HC(S)08".  It is assumed the reader is already familiar with terms like "EBNF Syntax", and the information is given in a very cryptic fashion.  The code examples given are sparse, and do not really explain the features of inline assembler that differ from normal assembler (that I am reasonably familiar with).  Within the code snippets, comments are virtually non-existent.
 
Additional addressing modes, not available in normal assembler, are not adequately explained.  I find the paragraph on "In & Gen Sets" very confusing.
 
I get the feeling that a 10 page limit must have been placed on the inline assembler section - it is well below the standard of other manuals, such as the Assembler manual.  Having said this, can anyone suggest additional information about inline assembler, perhaps in the form of a tutorial?
 
Regards,
Mac

Message Edited by CrasyCat on 2007-04-13 11:44 AM

Labels (1)
Tags (1)
0 Kudos
1 Solution
545 Views
CompilerGuru
NXP Employee
NXP Employee
Not sure what the point is about the not use of unsigned.
Maybe that using unsigned types also has its problems, for example:
unsigned int a; /* values 1..1000 */
int b; /* values -1000..+1000 */
  int less_a_b(void) {
  return a < b; /* unsigned compare! */
}

Basically mixing signed and unsigend may cause troubles, if you are not very familiar with the ANSI C standard.
Using "int a" in this (constructed) sample would cause the expected behavior of a singed compare.

Anyway, I don't think that signed arithmetic is "much more complex", I would say it's a bit more expensive in some cases.

I don't have the manual in front of me, but the "In & Gen Sets" are to tell the compiler which register are really needed (when this is not obvious given the instruction). For example, for an HLI RTS the compiler does assume that every register is returned. If the code does explicitly state that for the RTS, the H and X don't have to be preserved, then the compiler can use those registers for accessing the stack.
(instead of a ADD 1,SP -> TSX; ADD 0,X)
In other words, you don't have to specify those sets. If you do not, then the generated code may miss some optimization opportunities.


Daniel

View solution in original post

0 Kudos
3 Replies
546 Views
CompilerGuru
NXP Employee
NXP Employee
Not sure what the point is about the not use of unsigned.
Maybe that using unsigned types also has its problems, for example:
unsigned int a; /* values 1..1000 */
int b; /* values -1000..+1000 */
  int less_a_b(void) {
  return a < b; /* unsigned compare! */
}

Basically mixing signed and unsigend may cause troubles, if you are not very familiar with the ANSI C standard.
Using "int a" in this (constructed) sample would cause the expected behavior of a singed compare.

Anyway, I don't think that signed arithmetic is "much more complex", I would say it's a bit more expensive in some cases.

I don't have the manual in front of me, but the "In & Gen Sets" are to tell the compiler which register are really needed (when this is not obvious given the instruction). For example, for an HLI RTS the compiler does assume that every register is returned. If the code does explicitly state that for the RTS, the H and X don't have to be preserved, then the compiler can use those registers for accessing the stack.
(instead of a ADD 1,SP -> TSX; ADD 0,X)
In other words, you don't have to specify those sets. If you do not, then the generated code may miss some optimization opportunities.


Daniel
0 Kudos
545 Views
bigmac
Specialist III
Hello Daniel,
 
Thank you for your response.
 
So the "real" issue is the mixing of signed and unsigned types in a single expression, without proper precautions.  Perhaps the manual should have been more explicit.
 
When using unsigned types, I tend to use the macro substitutions of byte, word and dword.  As well as fewer characters to enter, their use tends to make the unsigned types more obviously different than the signed types, for me.
 
Do you know of an alternative reference document for CW inline assembler?  Am I correct in assuming that this is compiler dependent, and outside the scope of ANSI C?
 
Regards,
Mac
 
0 Kudos
545 Views
CompilerGuru
NXP Employee
NXP Employee
Well, about this unsigned manual statement, I don't know if this was the point the original author did intend to make. Maybe. It's just my note why blindly using unsigned, if values are never negative, does not work in all cases too.
About the manual, sorry, I don't have another manual for you.
Having a look at the runtime support (lib\hc08c\src\rtshc08.c) may also help a bit, at least this code does make use of the "In & Gen Sets".

HLI is of course very processor and compiler specific. I think ANSI C defines the keyword asm and that it is implementation specific. And that's about it. Everything else is beyond ANSI C.


Daniel
0 Kudos