[Tinycc-devel] (no subject)
How do I start contributing technical documentation to the community as I am a member of the mailing list but I'm a first time user of the mailing list and bug report systems please explain the process of report systems also I want to use doxygen to generate doctests and comments on tcc source code also of the busybox version first.Thanks Zebb ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] (no subject)
TCC generates object code directly. There is no assembly intermediate step, hence tcc -S does not work. On Sat, 26 Feb 2022 21:14:49 -0500 Yair Lenga wrote: > I'm interested in understanding the code generation logic of tcc. > > Is there away to see the intermediate representation that tcc > generates between the "C" source code, and the object file. > documentation indicates there tcc can compile assembly source code to > object, but I could not not find the equivalent of "gcc -S", which > should convert the "C" code into assembly. > > Yair ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] (no subject)
Hi, I'm interested in understanding the code generation logic of tcc. Is there away to see the intermediate representation that tcc generates between the "C" source code, and the object file. documentation indicates there tcc can compile assembly source code to object, but I could not not find the equivalent of "gcc -S", which should convert the "C" code into assembly. Yair ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] (no subject)
Hi Andy, On Fri, May 10, 2019 at 07:30:24PM +0300, ANDY TAKKER wrote: > A lot of words are said about compatibility and portability, but GCC > and PCC bring one result, and TCC is completely different. Let's for a second assume that you run that code on an architecture with sizeof(char*) == sizeof(int). Why should TCC generate the same output as GCC and PCC? You attempt to skip the prologue of the function by adding 3 to the address, but the prologue is not standardized. The one used by TCC is different from the one used by GCC. Just compare the output of GCC with -O0 and GCC with -O3 -fomit-frame-pointer. That should also give you different results. And with -O3 GCC might even decide to omit that asm statement because it has no needed outputs, doesn't clobber anything and isn't marked as volatile. > Here is > another interesting link closely related to the TCC. > https://forum.nasm.us/index.php?topic=2524.0 If you have access to the output of that obscure mix of compiler, assembler, and linker, please provide the disassembly of the _start function. > nop jump: Sometimes TCC has to reserve space for an instruction before it knows if it is needed or how long it will be. To fill the gaps, it uses nops. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] (no subject)
Hi, everybody. Fabrice keep silence.
So, maybe someome of you can help.
I can't compile such a simple programm:
//RDTSCP cpuid
#include
main()
{
unsigned int a;
b:
asm ( "cpuid" );
asm ( "rdtsc" );
asm ( "mov %eax, a" );
printf("%d\n", a);
goto b;
}
Evil tongues from
https://sites.google.com/site/excelmidi/universal_student_ide/universal_student_ide_en
claim that TCC inline Assembler
not see local variables. I don't believe.
TCC such old. What I do wrong?
And don't tell me, that I'm first in the
world, who try to use inline Asm in TCC. :)
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] (no subject)
I figured I'd reply to my own questions:
1) When compiling resources, just sticking with windres 32 bit hacked to
call tcc seems to generate working resources, that will link into both 32
and 64-bit code.
2) I traced my issues with not being able to call certain comdlg32
functions, to issues with structure packing. Commenting out the #pragma
pack(push,1) in commdlg.h fixed it, and now I have working code in 32-bit
and 64-bit. 32-bit seems to like 1-byte alignment, and 64-bit presumably
defaults to 8-byte alignment.
Thanks so much everyone that's worked on this!
Best Wishes,
Jonathan
Hi,
I've been able to successfully use windres to compile, then tcc 0.9.26 to
link resources into a 32-bit program.
However, I'm kinda stuck trying to get tcc to link to a 64-bit windres
generated resource file.
1) Check for magic not yet supporting x86-64
In file tccpe.c, the pe_load_res is looking for 32-bit magic
//if (hdr.filehdr.Machine != 0x014C
if (hdr.filehdr.Machine != 0x8664
|| hdr.filehdr.NumberOfSections != 1
|| strcmp(hdr.sectionhdr.Name, .rsrc) != 0) {
printf(Machine: %lx, hdr.filehdr.Machine);
goto quit;
}
2) Resource files appear to be slightly different between win32 and x86-64
The reltype shows up as 3 in my compiled 64-bit resource but tcc is
expecting 7.
lower in same function...
printf(rsrc_reloc: %x %x %x\n, rel.offset, rel.size, rel.type);
// debugging
if (rel.type != 7) /* DIR32NB */ {
printf(ERROR: rel.type != 7 Got: %d\n,rel.type); //
prints a 3 for 64-bit resources
goto quit;
}
Has anyone pushed a bit further and managed to get tcc linking to 64-bit
resources?
Best Wishes,
Jonathan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] (no subject)
DWORD64 WINAPI SymLoadModuleEx( __in HANDLE hProcess, __in HANDLE hFile, __in PCTSTR ImageName, __in PCTSTR ModuleName, __in DWORD64 BaseOfDll, __in DWORD DllSize, __in PMODLOAD_DATA Data, __in DWORD Flags ); ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] (no subject)
Come on, no Female stuff? ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] (no subject)
i have installed tcc-0.9.25 in red hat linux. i want to know how start inafter installatin. -- SHESH NATH RESEARCH SCHOLAR, THEORETICAL CONDENSED MATTER PHYSICS, DEPARTMENT OF PHYSICS, BANARAS HINDU UNIVERSITY, VARANASI-221005 ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] (no subject) - array[restrict] problem
Pedro A ARANDA wrote: Hi the current git version of TinyCC chokes at one of my scripts: p...@paag:~.../Devel$ syncp tinycc_1.0.0-pre2_i386.deb /media/Philips\ External\ Hard\ Disk/ In file included from /home/paag/bin/syncp:16: /usr/include/regex.h:543: identifier expected p...@paag:~.../Devel$ SciTE /usr/include/regex.h The offending line in regex.h is: extern int regexec (const regex_t *__restrict __preg, const char *__restrict __string, size_t __nmatch, regmatch_t __pmatch[__restrict_arr], int __eflags); This doesn't happen with Landley's mercurialtcc. Cheers,/PA Patch pushed at: http://repo.or.cz/w/tinycc.git?a=commitdiff;h=d23f7ed32ae7f34deb06de15a169ca61f5a62c5d --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
RE: [Tinycc-devel] (no subject)
The error must be earlier in your code. I included the macro in a simple C program and it compiled and ran OK. Message: 1 Date: Wed, 21 Mar 2007 10:46:14 +0800 From: ??? [EMAIL PROTECTED] Subject: [Tinycc-devel] (no subject) To: tinycc-devel@nongnu.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=utf-8 when i want to use tcc to compile lwc(Lightweight C++http://students.ceid.upatras.gr/%7Esxanth/lwc/) appear below message lex.c:XXX: ';' expected i am use tcc 0.9.23 whether is the problem to tcc parse below sentence ? code #define SAVE_VAR(x, y) __typeof__(x) _tmp_ ## x = x;x = y /code it work well to gcc4.0.3 -- sguzwf ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] (no subject)
when i want to use tcc to compile lwc(Lightweight C++http://students.ceid.upatras.gr/%7Esxanth/lwc/) appear below message lex.c:XXX: ';' expected i am use tcc 0.9.23 whether is the problem to tcc parse below sentence ? code #define SAVE_VAR(x, y) __typeof__(x) _tmp_ ## x = x;x = y /code it work well to gcc4.0.3 -- sguzwf ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] (no subject)
Hi, On 9/13/06, Dave Dodge [EMAIL PROTECTED] wrote: On Tue, Sep 12, 2006 at 11:46:45AM -0400, Rob Landley wrote: [..] The problem is that for the workloads where IA-64 is king, there's things like huge core counts and RAM sizes that the other hardware can't easily reach yet. If AMD can get Opteron scaled up to those levels, though, it'll probably be the final nail in Itanium's coffin. Can't Opteron natively scale up to 8 sockets (so 16 core with dual-code) natively? Can't Opteon address already enough RAM for all realistic workloads? The only shortcoming I see with Operon (right now) is the size of its cache, not the size of the addressable memory nor the number of core... ... or am I missing smth? Guillaume -- With DADVSI (http://en.wikipedia.org/wiki/DADVSI), France finally has a lead on USA on selling out individuals right to corporations! Vive la France! ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] (no subject)
On Monday 11 September 2006 6:20 pm, Dave Dodge wrote: On the other hand you have platforms like IA-64, where in theory a good compiler can get much better results than a bad compiler no matter how good the incoming code is. This sort of architecture requires the compiler to explicitly reorder, bundle, group, and schedule instructions ahead of time to hit the functional units on the chip in the best way. I think compiler design for IA-64 is an active research area at several universities. Translation: Itanic sucks so badly that it takes a near-miraculous compiler to get even reasonable performance out of it, although we try to phrase it to seem like it's the compiler's fault. I wouldn't consider the second coming of the i432 to be TCC's problem. I do not buy the our chip design's great, it's just that every C compiler produced over the last 30 years sucks argument. There's plenty of hardware out there that can get better performance out of fewer transistors, fewer watts, and without requiring an NP-complete (or AI-complete) optimizer to hide its most obvious shortcomings. Rob -- Never bet against the cheap plastic solution. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] (no subject)
Guillaume POIRIER wrote: Hi, On 9/7/06, Mike B [EMAIL PROTECTED] wrote: Is there a road map, or a todo list for this project? I was wondering how much work there is to do to make this into a GCC drop in replacement? Please keep in mind that the years of experience that GCC has make it generate much better code that TCC can right now, and probably ever will. So if you're after just being able to replace gcc with a fast compiler, TCC can broaden its support of C language up to the point that it will compile most of C codes you throw at it... However, it's just not an achievable goal right now to expect TCC outperform GCC in code generation quality. It's all a matter of manpower and experience. Guillaume In fact, it depends on what you mean by drop in replacement. Of course, gcc generated code runs much faster. But as tcc generates code much faster, it may be very comfortable for everyday work to use it. While debuging everyday code, compilation time may be more critical than execution speed. For this to be practical, you need tcc to be a drop in replacement, which in this context mainly means: - support the same command line options (no need to rewrite all Makefiles), even if some (optimisations for example) are simply ignored - support the same syntax (which here means gcc extensions) Compiling the Linux kernel in few seconds is quite great, changing all Makefiles to do it would (is?) be unsatisfactory. -- Philippe Ribet The README file said Requires Windows 95, NT 4.0, or better. So... I installed it on Linux! ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] (no subject)
Hi, On 9/7/06, Mike B [EMAIL PROTECTED] wrote: Is there a road map, or a todo list for this project? I was wondering how much work there is to do to make this into a GCC drop in replacement? Please keep in mind that the years of experience that GCC has make it generate much better code that TCC can right now, and probably ever will. So if you're after just being able to replace gcc with a fast compiler, TCC can broaden its support of C language up to the point that it will compile most of C codes you throw at it... However, it's just not an achievable goal right now to expect TCC outperform GCC in code generation quality. It's all a matter of manpower and experience. Guillaume -- With DADVSI (http://en.wikipedia.org/wiki/DADVSI), France finally has a lead on USA on selling out individuals right to corporations! Vive la France! ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] (no subject)
However, it's just not an achievable goal right now to expect TCC outperform GCC in code generation quality. It's all a matter of manpower and experience. that depends on how you look at the way you write code... just to expect that a compiler does a better way optimizing stuff than a good programmer would, is a wrong assumption. you can think and/or believe that ofcourse, but its simply not true. indeed its experience that make good code run faster, not just a compiler. not saying that gcc is a bad compiler, but i'm not sure one can call gcc a great compiler in the first place. cheers, johannes 2006/9/8, Guillaume POIRIER [EMAIL PROTECTED]: Hi, On 9/7/06, Mike B [EMAIL PROTECTED] wrote: Is there a road map, or a todo list for this project? I was wondering how much work there is to do to make this into a GCC drop in replacement? Please keep in mind that the years of experience that GCC has make it generate much better code that TCC can right now, and probably ever will. So if you're after just being able to replace gcc with a fast compiler, TCC can broaden its support of C language up to the point that it will compile most of C codes you throw at it... However, it's just not an achievable goal right now to expect TCC outperform GCC in code generation quality. It's all a matter of manpower and experience. Guillaume -- With DADVSI (http://en.wikipedia.org/wiki/DADVSI), France finally has a lead on USA on selling out individuals right to corporations! Vive la France! ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel -- met vriendelijke groet, johannes klarenbeek ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] (no subject)
hi all, Is there a road map, or a todo list for this project? I was wondering how much work there is to do to make this into a GCC drop in replacement? Mike ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] (no subject)
Is argv[0] broken? Printing if with the -b (bounds check) gives a
segfault, but all is well without -b.
[EMAIL PROTECTED] src]$ cat name.c
#include stdio.h
main(int argc, char **argv)
{
puts(argv[0]);
}
[EMAIL PROTECTED] src]$ tcc -run -b -Wall name.c
Runtime error: dereferencing invalid pointer
at 0x098dce48: main() (name.c:5)
by 0x08067e07: ???
by 0x08069e3f: ???
by 0x00881e23: ???
by 0x08048961: ???
Segmentation fault
[EMAIL PROTECTED] src]$ tcc -run -Wall name.c
name.c
[EMAIL PROTECTED] src]$
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] (no subject)
___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
