[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Progress on the Thumb2 generator, testing

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]
Sent: Monday, April 06, 2020 21:50
To: address@hidden; address@hidden
Subject: Re: [Tinycc-devel] Progress on the Thumb2 generator, testing




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 😊




Fra: Tinycc-devel <tinycc-devel-bounces+erlend.sveen=address@hidden> på vegne av Christian Jullien <address@hidden>
Sendt: søndag 5. april 2020 18:14
Til: address@hidden <address@hidden>
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);





    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
Sent: Sunday, April 05, 2020 17:19
To: address@hidden
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



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



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).



Erlend Sveen

reply via email to

[Prev in Thread] Current Thread [Next in Thread]