When compiling with -mint8 GCC option and trying this
const Tuint16 xxx = 8000000
or any other type (double, long, Tdouble…) I get following warning:
- integer constant is too large for 'long' type
- overflow in implicit constant conversion
.
In fact anything with 8.000.000 will fail (#define, …).
Help: How to use BIG? numbers
When compiling without -mint8 no problem.
My avr-libc manual clains:
There is a -mint8 option (see Options for the C
compiler avr-gcc) to make int 8 bits, but that is not supported by avr-libc and
violates C standards (int must be at least 16 bits). It may be removed in a future
release.
?????
Does it work or not?
Can one compile without it? Will this brake OS?
What to do?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To be short -mint8 makes code a lot denser, because it prohibits 16bit integer promotion on intermediate calculations, that are 8bit in the end. Depending on your application it can make a 10% to 20% difference in code size. And remember, my first design goal was to make a small OS.
Actually, it would be a lot better if gcc would natively support 8 bit arithmetic. But it does not, so a dirty trick was invented. Basically, this boils down to shifting all integer types 'one level' down in size. So 16 bit becomes 8bit, 32 bit becomes 16 bit, and 64 bit becomes 32 bit. Working with 64 bit types (long long) is not possible any more.
I choose to make use of this option, although my OS does not depend on it. I know avr-libc does not support it, but i do not make use of avr-libc that much. And most part of the library do work with the option, the designers only do not guarantee it (and you do not get any support from them if they find out you use the extension . And yes, some functions do behave strangely.
Now to your question.
const Tuint16 xxx = 8000000;
What i do not understand, Tuint16 is meant to hold 16 bit numbers, so 8000000 is too large anyway. (maximum 16bit unsigned value is 65535). You should try (untested, i never needed such large numbers)
const int32_t xxx = 8000000LL;
This should work, and be treated as a proper 32 bit variable with the -mint8 option.
Note that all examples in my distro are optimized for -mint8 and do not work when you compile them without, except the Hello World example. That one is not optimized at all, so should run without that option.
Last remark. I always have developed with -mint8, so do not have much experience without. It might be that you encounter something strange, please report if you do. It is my goal that Femto OS runs with and without the -mint8 option.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just forget Tuint16 stupidity. Anyway I tried to put baudrate prescaler in UBRRL and UBRRH using #defines from ATmega docs. And all the time I got this warning. Then I used variables but always thought small numbers. Add to this problems with UBRRL and you get me going nuts.
Anyway HelloWorld example compiles and runs without -mint8. No problem.
Thanks for quick response. This should get me on tracks again.
Best regards
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When compiling with -mint8 GCC option and trying this
or any other type (double, long, Tdouble…) I get following warning:
.
In fact anything with 8.000.000 will fail (#define, …).
Help: How to use BIG? numbers
When compiling without -mint8 no problem.
My avr-libc manual clains:
?????
Does it work or not?
Can one compile without it? Will this brake OS?
What to do?
To be short -mint8 makes code a lot denser, because it prohibits 16bit integer promotion on intermediate calculations, that are 8bit in the end. Depending on your application it can make a 10% to 20% difference in code size. And remember, my first design goal was to make a small OS.
Actually, it would be a lot better if gcc would natively support 8 bit arithmetic. But it does not, so a dirty trick was invented. Basically, this boils down to shifting all integer types 'one level' down in size. So 16 bit becomes 8bit, 32 bit becomes 16 bit, and 64 bit becomes 32 bit. Working with 64 bit types (long long) is not possible any more.
I choose to make use of this option, although my OS does not depend on it. I know avr-libc does not support it, but i do not make use of avr-libc that much. And most part of the library do work with the option, the designers only do not guarantee it (and you do not get any support from them if they find out you use the extension . And yes, some functions do behave strangely.
Now to your question.
What i do not understand, Tuint16 is meant to hold 16 bit numbers, so 8000000 is too large anyway. (maximum 16bit unsigned value is 65535). You should try (untested, i never needed such large numbers)
This should work, and be treated as a proper 32 bit variable with the -mint8 option.
Note that all examples in my distro are optimized for -mint8 and do not work when you compile them without, except the Hello World example. That one is not optimized at all, so should run without that option.
Last remark. I always have developed with -mint8, so do not have much experience without. It might be that you encounter something strange, please report if you do. It is my goal that Femto OS runs with and without the -mint8 option.
Just forget Tuint16 stupidity. Anyway I tried to put baudrate prescaler in UBRRL and UBRRH using #defines from ATmega docs. And all the time I got this warning. Then I used variables but always thought small numbers. Add to this problems with UBRRL and you get me going nuts.
Anyway HelloWorld example compiles and runs without -mint8. No problem.
Thanks for quick response. This should get me on tracks again.
Best regards