Floating Point Support for HCS08

[Dakota]

Good Morning,

I have used floating-point operations in HC08 processors for many years, but this is the first time that I have tried it with an HCS08 processor.  I am trying to multiply a floating-point number and a short, and the processor simply hangs up.  I have plenty of stack space and plenty of memory.  Here are the significant lines of code:

 float Kp;

short E;

float temp;

short Rs;

 Rs = RS232RX << 2;

E =  Rs - A2D0[0];

// proportional controller

temp = Kp * E;                                    // this hangs

if(temp > 1023)

    temp = 1023;

else if(temp < -1023)

    temp = -1023;

PWM0 = (short)temp;

 The code hangs up at the line:

 E =  Rs - A2D0[0];

 I then tried to typecast E from a short to a float before the multiply:

 float Efloat;

 Efloat = (float)E;                                   // this hangs

 It hangs up on the typecast.  Interestingly, if I comment out that line and set the values to constants, the typecast from float to short works fine:

 PWM0 = (short)temp;                          // this is OK

 I am using the ansitfs library.  Any help would be greatly appreciated.

 Thank you.

[Dakota]

After seeing my original message online, I realized that it is a bit verbose.  To the point, Code written with CodeWarrior for HCS08, using the ansitfs library, seems to hang up when typecasting from a short to a float, or when typecasting from an int to a float.  It also hangs up when trying to multiply a short and a float.  It does seem to work fine, however, when typecasting from a float to an int or short.

Has anyone seen this problem, and is there a solution?

Thank you.

[CompilerGuru]

No, did not see this.
But can you show where it actually hangs for you? Maybe with a screeshot (so also the registers and the memory around the SP is visible)?

Also which core are you using, and is everything in the zero page as required by the tiny memory model?
Which compiler options do you use?
ansitfs.lib is for IEEE32/32 tiny memory model for the S08.

Daniel

[Dakota]

Good Morning,

I created the project using the IEEE32/32 tiny memory module, and have not changed any of the compiler settings.  I have created many variables in higher memory using the #pragma DATA_SEG FAR FAR_RAM statement, and these variables do not seem to create any problems (I access them with no errors).  The problem only occurs when I tried to multiply an integer and a float.  I have worked around the problem by multiplying my floating point number by 64, performing integer multiplication, and then bit shifting the result to the right by 4.  Using this workaround, my entire project works well, although the code is somewhat difficult to read, and I would much rather use the floating-point multiplication.

When troubleshooting the problem, I tried multiplying a float and a float – that worked fine.  I then tried multiplying an integer and an integer – that also worked fine.  The problem only occurs when trying to multiply a float and an integer.  I then tried to typecast the integer to a float before performing the multiplication – and that is where the problem occurred.

I have attached a screenshot of the emulator screen stopped at the point where it hangs.  I would also gladly send you the project, if you are interested.  It is a small project, and it is not proprietary.

Thank you.

[CompilerGuru]

As far as I know, tiny means that all non explicitely allocated variables must be in the zero page, and this
does include the stack.
The current SP in the screenshot is 0x246, so I would suggest not to use the tiny memory model,
but instead the small memory model and to explicitely allocate all the variables you want in the zero page.

Daniel

[Dakota]

Good Morning,

In CodeWarrior v6, when a new project is created using the tiny memory module, the following message appears:

“By default all variables are in the zero page (direct memory access). Variables outside the zero page can be used with pragmas or the far keyword.”

I used pragmas to locate commonly used variables outside of the zero page (such as my PWM values, the A2D array, and other data collection variables).  I also located the stack in high memory (in the .prm file).  Memory location 0x246 is within my stack.  This is the seventh project in which I have used this same configuration (I just create a new folder, copy the old files into it, and open this copied project as a starting point).  Every project has worked with no problem – the high memory variables can be accessed, the new variables created go into low memory, and the stack works as expected.

The only problem that I have is multiplying a float and an integer (as I mentioned integer*integer and float*float works fine). The problem seems to be in casting the integer to a float (casting the float to an integer also works fine).

I have a work-around and, in fact, my work-around runs faster than the library floating point multiply routine.  It just makes the code a little difficult to understand.

Thank you.

[CompilerGuru]

I must admit that the text in the wizard (or the maual, AFAIK) does not explicitly mention the stack, but it really is supposed to be in the zero page too for the tiny memory model. So "all variables" includes the ones on the stack.

"normal" accesses to stack variables do not cause any problems even if the stack is allocated outside of the zero page, however there are certain otherwise perfectly legal C constructs, like you integer to float conversion, where the compiler does generate code with the assumption that the stack is in the zero page. And if you do not place it there, then those constructs will fail. Unfortunately stack are coded completely without the linker, and only the linker does know where you stack ends up (and eventually not even the linker, if you have multiple stacks or do not use the provided support).
Anyway, so to summarize, if you do not place the stack into the zero page, then you may run into issues. But I do see that a lot of reasonable code will run just fine. Your choice.
To be on the safe side, I would use the small memory model and place all but the variables you currently place extended explicitly in the zero page.

Daniel

PS: Something else which is not reliable with SP beyond 0xFF and tiny: Struct returns.

[Dakota]

Thank you for the information.  For future projects, I will try the small memory model (it is a little late for this one).  It seems that the tiny memory model is really only intended for memory usage up to FF.

In the small memory model, is the stack restricted to high memory (the message states that all variables are placed in high memory)?  It seems that, for the small memory model, variables placed in low memory (zero page) must be defined with a pragma.  Will I have the same problem?  In other words, with the small memory model, will I only be able to use high memory if I want to perform floating point operations?

[CompilerGuru · Accepted solution]

Not sure I understand the question.

In the tiny memory model, everything outside the zero page must be explicitly placed with a pragma.
In the small memory model, everything which should take advantage of zero page addressing and which should be allocated in the zeropage has to be explicitly qualified with a pragma instead.
However a failure in doing so in the small memory model only causes that the compiler wont take advantage of the more efficient zero page addressing modes, it still will just work fine though.
For locals (on the stack), I would not expect a significant increase in code size when using small versus tiny.
For globals tiny/using zero page is more efficient, and therefore I would allocate the often used variables in the zero page when using the small memory model and the code efficiency/size is critical.

In the small memory model the stack can be anywhere in the 64k addressing range, well it should have RAM there :smileyhappy:. The stack can be (even partially) in the zero page, but there is no advantage in doing so. So I would fill the zero page with globals instead.

Daniel

[Dakota]

Thank you.  I think that you answered my question.  For future projects, I will use the small memory model and place commonly used global variables in the zero page with a pragma.  That way, the floating point routines should work as expected.