You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With regard to improve OpenWatcom stuff I found one case where libc could be improved get it smaller a little bit.
The libc library is primarily compiled by gcc (16-bit) and it uses signed char (default) for plain char, but OpenWatcom uses unsigned char (default). When I play with OpenWatcom stuff improvement I checked generated code and using of unsigned char for plain text get smaller generated code.
Anyway now it is mismatch between GCC and OpenWatcom that it should be corrected.
Simple solution is switch OpenWatcom to use signed char for plain char, because most of testing was done with executable generated by GCC with signed char type for plain char, but code will be a little bigger.
Unsigned char get a little bit smaller code that it can be switch to use unsigned char also for GCC, but it is not possible without review of code which use plain char because there can be issue with signed/unsigned values not generally but on some places in code.
This issue is rather for future development to optimize size of ELKS libc.
The text was updated successfully, but these errors were encountered:
jmalak
changed the title
Use of plain char as signed char is not optimal
Use of plain char as signed char in libc is not optimal
Jul 28, 2024
With regard to improve OpenWatcom stuff I found one case where libc could be improved get it smaller a little bit.
The libc library is primarily compiled by gcc (16-bit) and it uses signed char (default) for plain char, but OpenWatcom uses unsigned char (default). When I play with OpenWatcom stuff improvement I checked generated code and using of unsigned char for plain text get smaller generated code.
Anyway now it is mismatch between GCC and OpenWatcom that it should be corrected.
Simple solution is switch OpenWatcom to use signed char for plain char, because most of testing was done with executable generated by GCC with signed char type for plain char, but code will be a little bigger.
Unsigned char get a little bit smaller code that it can be switch to use unsigned char also for GCC, but it is not possible without review of code which use plain char because there can be issue with signed/unsigned values not generally but on some places in code.
This issue is rather for future development to optimize size of ELKS libc.
The text was updated successfully, but these errors were encountered: