Re: [Tinycc-devel] _Generic or __builtin_choose_expr

[uso ewin]

On Fri, Jul 14, 2017 at 7:22 AM, Christian Jullien  wrote:
> It's nice to see new features coming on tcc, but it's also nice if they work
> everywhere
> _Generic author(s) can you please take time to fix failing test?
>
> Test: 94_generic...
> --- ../../tests/tests2/94_generic.expect2017-07-10
> 23:00:46.045513740 +0200
> +++ 94_generic.output   2017-07-14 07:12:25.965274077 +0200
> @@ -1,9 +1 @@
> -20
> -20
> -123
> -2
> -5
> -1
> -2
> -3
> -1
> +94_generic.c:44: error: type march twice
>
> IMHO, your test depends on how different types are implemented in native
> machine. So it's more a test issue than an implementation issue.
> May be? Using 'portable' types like uint32_t may solve some issues. You may
> also solve const/non const issue signed/unsigned char by forcing an exact
> type OR by giving the same value whether string is const or not.
>
> In any cases, 94_generic should produce NO error on platform tcc supports.
> I'll be on vacation next two weeks and have limited time to investigate
> myself but I'll be glad to test changes on Windows 32/64 and RPi
>

Hello,

Sorry if I take time to answer,
So actually it's not a test issue, because gcc can do difference
between a 'char *' a 'signed char *', and a 'unsigned char *',
gcc doesn't consider int and a typedef of an int as the same type,
and most important it will find the good match to a long.

grischka seems to have fix char * problem,
I've just push a fix for the long on my github,
but it does refactor how VT_LONG is handle so I’m not very confident
on pushing it now on mob without a review
(this is why it take me time to answer).

I've also fix all type.

for the typedef, I guess it might work, but I didn't check further yet.

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Crutches_for_TCC_inline_Asm

[Daniel Glöckner]

On Fri, Jul 14, 2017 at 10:07:55AM +0300, ANDY TAKKER wrote:
> As I see, there are no good teaches among tinycc-devel.

Yeah, I know, I studied maths and cs, not pedagogy.

> So, let's go on. Next program compiling well, but
> linking bad.

>asm ( "mov %eax, a" );

Linking fails because it expects to find a symbol called "a" but
local variables can not be found in the symbol table.

> The next program compiling well, linking well,
> but brings bad results.


> unsigned int a = 0;
> 
>  int   main()
> {
> 
> unsigned int a;
> b:
>asm ( "cpuid" );
>asm ( "rdtsc" );
>asm ( "mov %eax, a" );
>   printf("%d\n", a);
> goto b;
> }

You should have guessed by now that it will store the value
in the global variable.

> A big piece of work has been done. But
> who really need this heap of trash:

As I wrote in my last eMail, the TCC inline assembler tries to be
compatible to GCC. If you are unhappy with that, use another
compiler.

Did you read the GCC documentation for the inline assembler syntax?
Did you understand it?
Then you should know that the correct way to to it is:

int   main()
{
unsigned int a;
int junk1, junk2, junk3;
b:
asm ( "cpuid\n"
  "rdtsc"
  : "=a"(a), "=b"(junk1), "=c"(junk2), "=d"(junk3));
printf("%u\n", a);
goto b;
}

> Of couse, Fabrice will never patch TCC. Because of because.
> It is life.

No. It's because Fabrice has left the project years ago.
And it does not need patching. It behaves as intended.

Best regards,

  Daniel

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] Crutches_for_TCC_inline_Asm

[ANDY TAKKER]

Crutches for TCC inline Asm.

The beginning of the story is here:
http://lists.nongnu.org/archive/html/tinycc-devel/2017-07/msg00031.html
http://lists.nongnu.org/archive/html/tinycc-devel/2017-07/msg00032.html

As I see, there are no good teaches among tinycc-devel.
So, let's go on. Next program compiling well, but
linking bad.

#include 

 int   main()
{

unsigned int a = 0;
b:
   asm ( "cpuid" );
   asm ( "rdtsc" );
   asm ( "mov %eax, a" );
  printf("%d\n", a);
goto b;
}

:0040 55  push ebp
:0041 89E5mov ebp, esp
:0043 81EC0400sub esp, 0004
:0049 90  nop
:004A B8  mov eax, 
:004F 8945FC  mov dword ptr [ebp-04], eax
:0052 0FA2cpuid
:0054 0F31rdtsc
mistake :0056 A3  mov dword ptr [], eax
:005B 8B45FC  mov eax, dword ptr [ebp-04]
:005E 50  push eax
:005F B8  mov eax, 
:0064 50  push eax
:0065 E8FCFF  call 0066
:006A 83C408  add esp, 0008
:006D EBE3jmp 0052
:006F C9  leave
:0070 C3  ret

The next program compiling well, linking well,
but brings bad results.

#include 

unsigned int a = 0;

 int   main()
{

unsigned int a;
b:
   asm ( "cpuid" );
   asm ( "rdtsc" );
   asm ( "mov %eax, a" );
  printf("%d\n", a);
goto b;
}

And now... THE CRUTCHES!!!

A good pattern, for all beginners, who
does not want to drown in such nonsense:

int src = 1;
int dst;
asm ("mov %1, %0\n\t"
"add $1, %0"
: "=r" (dst)
: "r" (src));
printf("%d\n", dst);

ENJOY!

#include 

unsigned int temp0;

 int   main()
{

unsigned int a;
b:
   a = 0;
   temp0 = a;
   asm ( "cpuid" );
   asm ( "rdtsc" );
   asm ( "mov %eax, temp0" );
   a = temp0;
  printf("%d\n", a);
goto b;
}

As you see, TCC inline Assembler
not see local variables. And it's
not evil tongues from
https://sites.google.com/site/excelmidi/universal_student_ide/universal_student_ide_en
  .

A big piece of work has been done. But
who really need this heap of trash:

#include 

 int   main()
{

int src = 1;
int dst = 0;

asm ("mov %1, %0\n\t"
"add $1, %0"
: "=r" (dst)
   : "r" (src));

printf("%d\n", dst);
}

:0040 55  push ebp
:0041 89E5mov ebp, esp
:0043 81EC0800sub esp, 0008
:0049 90  nop
:004A B80100  mov eax, 0001
:004F 8945FC  mov dword ptr [ebp-04], eax
:0052 B8  mov eax, 
:0057 8945F8  mov dword ptr [ebp-08], eax
:005A 8B45FC  mov eax, dword ptr [ebp-04]
:005D 89C0mov eax, eax
:005F 050100  add eax, 0001
:0064 8945F8  mov dword ptr [ebp-08], eax
:0067 8B45F8  mov eax, dword ptr [ebp-08]
:006A 50  push eax
:006B B8  mov eax, 
:0070 50  push eax
:0071 E8FCFF  call 0072
:0076 83C408  add esp, 0008
:0079 C9  leave
:007A C3  ret

Of couse, Fabrice will never patch TCC. Because of because.
It is life.

Welcome https://sites.google.com/site/excelmidi   . Check
your CPU. New funny bug all x86.  Forget about optimization:
https://sites.google.com/site/excelmidi/stupid-bug-x86-cpu-tupoj-bag-processora-h86
 :)!

___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel