Progress on the Thumb2 generator, testing

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Progress on the Thumb2 generator, testing

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

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Progress on the Thumb2 generator, testing

Christian Jullien-3

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=[hidden email]] On Behalf Of Erlend Sveen
Sent: Sunday, April 05, 2020 17:19
To: [hidden email]
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Progress on the Thumb2 generator, testing

Erlend Sveen
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=[hidden email]> på vegne av Christian Jullien <[hidden email]>
Sendt: søndag 5. april 2020 18:14
Til: [hidden email] <[hidden email]>
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=[hidden email]] On Behalf Of Erlend Sveen
Sent: Sunday, April 05, 2020 17:19
To: [hidden email]
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Progress on the Thumb2 generator, testing

Christian Jullien-3

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:[hidden email]]
Sent: Monday, April 06, 2020 21:50
To: [hidden email]; [hidden email]
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=[hidden email]> på vegne av Christian Jullien <[hidden email]>
Sendt: søndag 5. april 2020 18:14
Til: [hidden email] <[hidden email]>
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=[hidden email]] On Behalf Of Erlend Sveen
Sent: Sunday, April 05, 2020 17:19
To: [hidden email]
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Progress on the Thumb2 generator, testing

Erlend Sveen
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 <[hidden email]>
Sendt: tirsdag 7. april 2020 07:00
Til: 'Erlend Sveen' <[hidden email]>; [hidden email] <[hidden email]>
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:[hidden email]]
Sent: Monday, April 06, 2020 21:50
To: [hidden email]; [hidden email]
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=[hidden email]> på vegne av Christian Jullien <[hidden email]>
Sendt: søndag 5. april 2020 18:14
Til: [hidden email] <[hidden email]>
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=[hidden email]] On Behalf Of Erlend Sveen
Sent: Sunday, April 05, 2020 17:19
To: [hidden email]
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Progress on the Thumb2 generator, testing

Christian Jullien-3

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:[hidden email]]
Sent: Tuesday, April 07, 2020 10:09
To: [hidden email]; [hidden email]
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 <[hidden email]>
Sendt: tirsdag 7. april 2020 07:00
Til: 'Erlend Sveen' <[hidden email]>; [hidden email] <[hidden email]>
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:[hidden email]]
Sent: Monday, April 06, 2020 21:50
To: [hidden email]; [hidden email]
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=[hidden email]> på vegne av Christian Jullien <[hidden email]>
Sendt: søndag 5. april 2020 18:14
Til: [hidden email] <[hidden email]>
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=[hidden email]] On Behalf Of Erlend Sveen
Sent: Sunday, April 05, 2020 17:19
To: [hidden email]
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel