|
| From: | Christian Jullien |
| Subject: | Re: [Tinycc-devel] Progress on the Thumb2 generator, testing |
| Date: | Tue, 7 Apr 2020 07:00:19 +0200 |
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:address@hidden] 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=address@hidden> på vegne av Christian Jullien <address@hidden> 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=address@hidden] On Behalf Of Erlend Sveen 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 |
| [Prev in Thread] | Current Thread | [Next in Thread] |