Many thanks for the precisions.
About –cpu=thumb2, On Windows, there are two different binaries and tcc frontend chooses internally the right one based on –m32 or –m64 flag. You can probably do the same. If you have some material to test Thumb2 on RPi, I’ll be glad to test. To test tcc on different platforms, I first uses tcc standard test suite I run from a very simple script I wrote, I also have scripts that do a huge non-regression tests suite for my OpenLisp ISLISP compiler. It tests many aspects of tcc with real bullet code. One of this test uses amalgamation technic which catenates all sources code (.c + .h) into a single 2.5M source file. Christian From: Erlend Sveen [mailto:erlend.sv...@hotmail.com] Sent: Tuesday, April 07, 2020 10:09 To: tinycc-devel@nongnu.org; jull...@eligis.com Subject: Re: [Tinycc-devel] Progress on the Thumb2 generator, testing Hi - From what I understand, Thump2 is a more compact code than standard arm one. Right? Thumb2 uses a mix of 16 and 32 bit encodings, so it is more compact. However it is not just a simple shrink. The 16-bit encodings will generally only operate with the lower registers 0-7. These same instructions also have alternate 32-bit encodings that can work will all registers. It is then up to the compiler to generate the best sequence. Also the 32-bit encodings are not the same as the ARM ones. For instance the thumb encodings do not have the condition flags for the majority of the instructions. Instead there is a new "it" instruction that can make other instructions conditional. There is also a proper divide instruction. Thumb and ARM code cannot be mixed without a processor mode switch, and most microcontrollers will not decode ARM at all. - On what board/Linux version do you test your work? I test on a stm32f767igt6 MCU, running an OS I've written myself (does not have a name yet). See the first mail for some extra info. It kinda fills the gap between most RTOSes and Linux: POSIX compatible interfaces when possible, full memory protection (I think Linux requires requires the full deal with paging/virtual memory etc for it to work, mine does with the much more primitive MPU hardware), dynamic loading of executables (rare to do on an MCU but I use it a ton), virtual file systems etc., and it still fits within kilobytes of ROM/RAM. Of course I'll be happy to elaborate if you have more questions, it has much more features than those! - Is there a change I can use Thumb2 backend on a Raspberri Pi 3 or 4? How? I did a quick search and it seems the RPI should be able to run thumb. But there is a possible problem: Code on RPI normally runs the regular ARM instruction set, so it would have to switch back and forth between thumb and ARM when calling library functions. So tcc would need to now if it is calling an ARM function or thumb2 function to generate the correct branch. Or maybe this is a linker job. Really I have not checked, I only use thumb so no need for interwork. Probably a good thing to look into since RPI testing would be really helpful (much easier to get started with RPI than MCU). - If it can run on Rpi, do you intend to support something like –cpu=thumb2. Gcc has few –xxx=thumb options but I’ve no idea of what they do. I think that in order to support those compiler flags, TCC would need to change the instruction backend in runtime, and it does not look like it can. It could be done with function pointers but also an if check in the generator. Perhaps a bigger issue is that some of those flags take the full name of the CPU, so the compiler can know more details than just the instruction set family to generate code that is best for exactly that CPU. Of course if we only switch between thumb and ARM backend it gets much simpler as long as everything else is the same such as the register file etc. I’m definitively not a tcc maintainer but I try to help as much as I can, esp. I test almost every mob on Linux x86, x64, arm, arm64 and on Windows x86, x64. If possible, I’ll be glad to test Thumb2 backend too (with my OpenLisp among other things). Very cool! Do you have some sort of automated setup to test them all? Seems like some work. Erlend. _____ Fra: Christian Jullien <eli...@orange.fr> Sendt: tirsdag 7. april 2020 07:00 Til: 'Erlend Sveen' <erlend.sv...@hotmail.com>; tinycc-devel@nongnu.org <tinycc-devel@nongnu.org> Emne: RE: [Tinycc-devel] Progress on the Thumb2 generator, testing Good to know it helped you (and that my guess was correct). Few questions for my curiosity: - From what I understand, Thump2 is a more compact code than standard arm one. Right? - On what board/Linux version do you test your work? - Is there a change I can use Thumb2 backend on a Raspberri Pi 3 or 4? How? - If it can run on Rpi, do you intend to support something like –cpu=thumb2. Gcc has few –xxx=thumb options but I’ve no idea of what they do. I’m definitively not a tcc maintainer but I try to help as much as I can, esp. I test almost every mob on Linux x86, x64, arm, arm64 and on Windows x86, x64. If possible, I’ll be glad to test Thumb2 backend too (with my OpenLisp among other things). From: Erlend Sveen [mailto:erlend.sv...@hotmail.com] Sent: Monday, April 06, 2020 21:50 To: jull...@eligis.com; tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] Progress on the Thumb2 generator, testing Thanks! I had wchar_t defined as 2 instead of 4, and for some reason I did not realize. Probably because of the confusing error message. All of the important tests works now and I know the "why" for the ones that don't. I'll start cleaning up my repos. If anyone has some more feedback regarding the more general questions it would be greatly appreciated 😊 Regards, Erlend _____ Fra: Tinycc-devel <tinycc-devel-bounces+erlend.sveen=hotmail....@nongnu.org> på vegne av Christian Jullien <eli...@orange.fr> Sendt: søndag 5. april 2020 18:14 Til: tinycc-devel@nongnu.org <tinycc-devel@nongnu.org> Emne: Re: [Tinycc-devel] Progress on the Thumb2 generator, testing Hi Erlend, Congrat for your progress. Few hints to help you debug this. If it stops at the first char, it is “probably” because wchar_t has an incorrect size (like 2 vs. 4) compared to the string encoded with L”…”. It stops with the NUL wchar_t. // this file contains BMP chars encoded in UTF-8 #include <stdio.h> #include <wchar.h> int main() { wchar_t s[] = L"hello$$你好¢¢世界€€world"; wchar_t *p; { unsigned char* byte = (unsigned char*)&s[0]; int i; for (i = 0; i < sizeof(s); ++i) { printf("p=%p => %02X\n", byte, *byte); ++byte; } } printf("sizeof(wchar_t) %d\n", sizeof(wchar_t)); printf("sizeof(s) %d\n", sizeof(wchar_t)); for (p = s; *p; p++) { printf("p=%p => %04X\n", p, (unsigned) *p); } return 0; } Rpi4 gives: $ tcc foo.c -o foo && ./foo | more p=0xbeba3508 => 68 p=0xbeba3509 => 00 p=0xbeba350a => 00 p=0xbeba350b => 00 p=0xbeba350c => 65 p=0xbeba350d => 00 p=0xbeba350e => 00 p=0xbeba350f => 00 p=0xbeba3510 => 6C p=0xbeba3511 => 00 p=0xbeba3512 => 00 p=0xbeba3513 => 00 p=0xbeba3514 => 6C p=0xbeba3515 => 00 p=0xbeba3516 => 00 p=0xbeba3517 => 00 p=0xbeba3518 => 6F p=0xbeba3519 => 00 p=0xbeba351a => 00 p=0xbeba351b => 00 p=0xbeba351c => 24 p=0xbeba351d => 00 p=0xbeba351e => 00 p=0xbeba351f => 00 p=0xbeba3520 => 24 p=0xbeba3521 => 00 p=0xbeba3522 => 00 p=0xbeba3523 => 00 p=0xbeba3524 => 60 p=0xbeba3525 => 4F p=0xbeba3526 => 00 p=0xbeba3527 => 00 p=0xbeba3528 => 7D p=0xbeba3529 => 59 p=0xbeba352a => 00 p=0xbeba352b => 00 p=0xbeba352c => A2 p=0xbeba352d => 00 p=0xbeba352e => 00 p=0xbeba352f => 00 p=0xbeba3530 => A2 p=0xbeba3531 => 00 p=0xbeba3532 => 00 p=0xbeba3533 => 00 p=0xbeba3534 => 16 p=0xbeba3535 => 4E p=0xbeba3536 => 00 p=0xbeba3537 => 00 p=0xbeba3538 => 4C p=0xbeba3539 => 75 p=0xbeba353a => 00 p=0xbeba353b => 00 p=0xbeba353c => AC p=0xbeba353d => 20 p=0xbeba353e => 00 p=0xbeba353f => 00 p=0xbeba3540 => AC p=0xbeba3541 => 20 p=0xbeba3542 => 00 p=0xbeba3543 => 00 p=0xbeba3544 => 77 p=0xbeba3545 => 00 p=0xbeba3546 => 00 p=0xbeba3547 => 00 p=0xbeba3548 => 6F p=0xbeba3549 => 00 p=0xbeba354a => 00 p=0xbeba354b => 00 p=0xbeba354c => 72 p=0xbeba354d => 00 p=0xbeba354e => 00 p=0xbeba354f => 00 p=0xbeba3550 => 6C p=0xbeba3551 => 00 p=0xbeba3552 => 00 p=0xbeba3553 => 00 p=0xbeba3554 => 64 p=0xbeba3555 => 00 p=0xbeba3556 => 00 p=0xbeba3557 => 00 p=0xbeba3558 => 00 p=0xbeba3559 => 00 p=0xbeba355a => 00 p=0xbeba355b => 00 sizeof(wchar_t) 4 sizeof(s) 4 p=0xbeba3508 => 0068 p=0xbeba350c => 0065 p=0xbeba3510 => 006C p=0xbeba3514 => 006C p=0xbeba3518 => 006F p=0xbeba351c => 0024 p=0xbeba3520 => 0024 p=0xbeba3524 => 4F60 p=0xbeba3528 => 597D p=0xbeba352c => 00A2 p=0xbeba3530 => 00A2 p=0xbeba3534 => 4E16 p=0xbeba3538 => 754C p=0xbeba353c => 20AC p=0xbeba3540 => 20AC p=0xbeba3544 => 0077 p=0xbeba3548 => 006F p=0xbeba354c => 0072 p=0xbeba3550 => 006C p=0xbeba3554 => 0064 From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Erlend Sveen Sent: Sunday, April 05, 2020 17:19 To: tinycc-devel@nongnu.org Subject: [Tinycc-devel] Progress on the Thumb2 generator, testing Hello again. I have been making some good progress on the Thumb2 code generator. I'm now on the latest version of TCC, and have almost all of the tests in the tests2 directory working (excluding those using floats and/or inline asm). There is one test in particular that I'm struggling with, 97_utf8_string.c. TCC Seems to think that the string is an integer or something, printing these warnings: tinycc/tests/tests2/97_utf8_string_literal.c:7: warning: assignment makes integer from pointer without a cast tinycc/tests/tests2/97_utf8_string_literal.c:7: warning: cast between pointer and integer of different size Compiling with the regular ARM cross compiler makes the same instruction sequence. If I run the program it only prints the first character. Does anyone have an idea of what is happening here? --- Next question is about testing in general. From what I can tell, it seems like running the tests only run on the regular x86 version and does not check anything with the cross compilers. Is this correct? If so, how are the cross compilers tested? It looks like it only checks that it will compile ex3.c, and that compiling and running running all the tests requires a target system to do it on (as in, there is no emulation, check for generation of undefined instructions/malformed files or other things). Reason I'm asking is that I'm uncertain about how testing of arm-thumb-tcc fits into all of this. In order to do my testing, I've made a separate testing harness. A shell script compiles a list of the relevant tests with TCC and link them against the C library that I've written. Another script then transfers all the executables to the target filesystem. I wrote a simple test runner that uses posix_spawn to run all the tests on the microcontroller and compares the output. The OS supports most of the things needed by the tests and does full memory protection, which makes testing fairly straight forward. Even the grep test works (although it must be run manually). However the OS is fairly niche (I've written it), and runs on a microcontroller so the hardware is fairly specific. Any thoughts? The testing program could be made to work on Linux with little modification, so someone might find a use of it, but I'd like to hear some opinions on how to do this. Other than this I think it is getting ready for review soon. Hopefully someone will have time for a quick look. I'll put up a temporary repo somewhere when the time comes. Current testing hardware is: * stm32f767igt6 with Cortex-M7 @ 216 MHz * 8MiB of additional external RAM. * 8MiB of external NOR Flash for root filesystem. + A bunch of other peripherals If I'm not mistaken the Thumb2 generator should work with any Cortex-M3, M4 and M7 microcontrollers but I've not tested those CPUs yet (I have some lying around). Regards, Erlend Sveen
_______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
