Re: [Tinycc-devel] All known working ports
On Thu, Jan 14, 2021 at 12:17:23PM +0100, Christian Jullien wrote: > macOS | x64 | clang/tcc | Ok (only tcc static) You reported success with dynamic linking on June 21. Why only static this time? Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tiny c availability
On Thu, Jul 09, 2020 at 10:09:56AM +0200, Christian Jullien wrote: > Many starts with more than one :o) Even the Pirahã appear to agree that many doesn't start before three. > Five BIG projects is not that bad. > > Let me start with few I very often (if not daily) compile: > - OpenLisp (daily) > - bigz (daily) > - gnumake (every major version) > - sqlite (daily - part of OpenLisp build) > - tcc (almost daily) > > They already count for FIVE :o) But you talked about many people, not many projects, and you are only one person, unless of course you have a split personality. :P > What about a page referencing projects that build with tcc? That would also be useful to show what tcc is capable of compiling. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tiny c availability
On Thu, Jul 09, 2020 at 06:29:11AM +0200, Christian Jullien wrote: > We are many to use it daily as main C compiler for really big projects. It think that's a bit exaggerated. From what I saw on this list you can count the number of people who use it for "really big projects" on one hand. A few people turned to tcc because it can serve as a JIT compiler while being smaller and probably easier to use than LLVM. Many people that choose tcc see no benefit in using a big featureful optimizing proven-in-use toolchain but are happy about every second they don't have to wait for the compiler. I'd be happy to be proven wrong. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] (maybe dumb) licensing question
Hello Karl, On Wed, May 13, 2020 at 07:30:32AM -0700, Karl Yerkes wrote: > i have a project that uses tcc as a library. i "use TCC as a backend for > dynamic code generation" as mentioned here: > https://savannah.nongnu.org/projects/tinycc/. it includes *libtcc.h* and > links statically or dynamically to *libtcc*. what are my licensing options > for my project? for dynamic linking you are free to use any license you want on your code. For static linking, your project must be compatible to the LGPL v2 or later if you target ARM32. Other targets use a more permissive BSD-like license. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Fwd: Re: github
On Wed, Apr 22, 2020 at 10:44:37AM +0200, Robert Hölzl wrote: > I did macOS test with the help of vagrant. > > You can download any OS from their platform: > https://app.vagrantup.com/boxes/search > > and its very convenient as it automates the generation and > integration (ssh connection, shared folders, ...). > And as it is a VM it is 100% macOS (no emulation with its quirks) The thing is that the macOS license AFAIK allows the use only on Apple hardware. There is no "official" macOS VM on Vagrant. All macOS VMs you can find on Vagrant have been provided by users. In another project we are using a machine provided by MacStadium, but OSS projects need regular releases (and a logo) to quality for a free machine. Yes, they should really consider shared hosting for projects that don't need a dedicated machine... Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Questions regarding ARM Thumb code generation
Hi, On Sun, Mar 22, 2020 at 11:26:30AM +, Erlend Sveen wrote: > * The repository I found mentions a licensing issue. I've searched the > mailing list and found that the author of the original ARM codegen does not > want to re-license it. Personally, I don't mind leaving the license as is. > There is no way I will be able to write the thumb code gen from scratch, > so my code will be based on the ARM one and subject to the same issue. Do I > need to worry about this? It would really suck if my code gets dropped due > to relicensing in the future. since I am the one who does not want to relicense the ARM32 backend, I give you and everyone else permission to use my ARM backend code as a template for a backend for another instruction set as long as you release it as open source software under the license found in the RELICENSING file in TinyCC (or the LGPL). To me ARM Thumb is a different instruction set. My intention is not to hinder development of TinyCC. What I want to prevent is that TinyCC gets hidden in closed source products. The LGPL does allow commercial use. People just have to read and follow the license. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] WebAssembly backend
On Fri, Feb 14, 2020 at 03:58:09AM -0800, Charles Lohr wrote: > There isn't xtensa support, but that wouldn't be hard to add. Adding support for a specific Xtensa chip wouldn't be hard, but Xtensa allows the instruction set to be modified in various different ways when the cpu core is synthesized. GCC had support for Xtensa for several years before the ESP8266 came along, but it took some time until GCC learnt how to deal with the call0 calling conventions necessary for this chip. The tools provided by Tensilica to chipmakers spit out header files with lots of defines that you have to use in a compiler to know how to generate code for a particular chip. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] A stack-overflow in tinycc-f150f93/tccpp.c
Hi, On Tue, Dec 24, 2019 at 01:12:55PM +0800, magic googlo wrote: > The attachment includes the error message of stack-overflow.c and asan that > triggered the crash. Hope to help you fix this bug as soon as possible tinycc relies heavily on recursion and AFAIK it nowhere limits the recursion depth. Attached you can find a graph that contains only the cycles from tinycc's call graph (when compiled for x86-64 Linux). The call graph was generated by adding a printf to gcall_or_jmp. The few indirect calls have been resolved manually. Afterwards I have filtered the graph iteratively with shell commands and converted it to a dot file. Adding recursion depth limitation into all cycles of this graph is a lot of work. And if we add limitations, the question is how many recursions we allow. In your example the stack overflow was caused by lots of pointer dereferences. It is possible to write a valid C program that contains more pointer dereferences in a row than your example. Why should tinycc reject it? As far as I can see the worst that can happen is that your system runs out of memory. Or are there systems where the stack might be extended until it connects to other allocated memory areas? I suggest that you limit the size of the stack with ulimit -s or compile tcc with a compiler that can instrument the code to prevent stack overflows if you have to compile untrusted source code. Best regards, Daniel digraph "tcc cycles" { "asm_expr" -> "asm_expr_cmp"; "asm_expr_cmp" -> "asm_expr_sum"; "asm_expr_cmp" -> "next"; "asm_expr_logic" -> "asm_expr_prod"; "asm_expr_logic" -> "next"; "asm_expr_prod" -> "asm_expr_unary"; "asm_expr_prod" -> "next"; "asm_expr_sum" -> "asm_expr_logic"; "asm_expr_sum" -> "next"; "asm_expr_unary" -> "asm_expr"; "asm_expr_unary" -> "asm_expr_unary"; "asm_expr_unary" -> "next"; "asm_expr_unary" -> "skip"; "asm_global_instr" -> "next"; "asm_global_instr" -> "parse_asm_str"; "asm_global_instr" -> "skip"; "asm_global_instr" -> "tcc_assemble_inline"; "asm_instr" -> "next"; "asm_instr" -> "parse_asm_operands"; "asm_instr" -> "parse_asm_str"; "asm_instr" -> "skip"; "asm_instr" -> "tcc_assemble_inline"; "asm_int_expr" -> "asm_expr"; "asm_label_instr" -> "next"; "asm_label_instr" -> "parse_asm_str"; "asm_label_instr" -> "skip"; "asm_opcode" -> "next"; "asm_opcode" -> "parse_operand"; "asm_parse_directive" -> "asm_expr"; "asm_parse_directive" -> "asm_int_expr"; "asm_parse_directive" -> "next"; "asm_parse_directive" -> "set_symbol"; "asm_parse_directive" -> "skip"; "asm_parse_directive" -> "tcc_assemble_internal"; "asm_parse_reg" -> "next"; "asm_parse_regvar" -> "parse_operand"; "block" -> "asm_instr"; "block" -> "block"; "block" -> "decl"; "block" -> "decl0"; "block" -> "expr_const64"; "block" -> "gexpr"; "block" -> "lblock"; "block" -> "next"; "block" -> "skip"; "classify_x86_64_inner" -> "classify_x86_64_inner"; "compare_types" -> "is_compatible_func"; "compare_types" -> "is_compatible_types"; "decl0" -> "asm_global_instr"; "decl0" -> "asm_label_instr"; "decl0" -> "decl0"; "decl0" -> "decl_initializer_alloc"; "decl0" -> "expr_const"; "decl0" -> "gen_function"; "decl0" -> "next"; "decl0" -> "parse_attribute"; "decl0" -> "parse_btype"; "decl0" -> "skip"; "decl0" -> "skip_or_save_block"; "decl0" -> "type_decl"; "decl" -> "decl0"; "decl_designator" -> "decl_initializer"; "decl_designator" -> "expr_const"; "decl_designator" -> "next"; "decl_designator" -> "skip"; "decl_initializer_alloc" -> "asm_parse_regvar"; "decl_initializer_alloc" -> "decl_initializer"; "decl_initializer_alloc" -> "next"; "decl_initializer_alloc" -> "skip_or_save_block"; "decl_initializer" -> "decl_designator"; "decl_initializer" -> "decl_initializer"; "decl_initializer" -> "next"; "decl_initializer" -> "parse_init_elem"; "decl_initializer" -> "skip"; "decl_initializer" -> "skip_or_save_block"; "expr_and" -> "expr_cmpeq"; "expr_and" -> "next"; "expr_cmpeq" -> "expr_cmp"; "expr_cmpeq" -> "next"; "expr_cmp" -> "expr_shift"; "expr_cmp" -> "next"; "expr_cond" -> "expr_cond"; "expr_cond" -> "expr_lor"; "expr_cond" -> "gexpr"; "expr_cond" -> "next"; "expr_cond" -> "skip"; "expr_const1" -> "expr_cond"; "expr_const64" -> "expr_const1"; "expr_const" -> "expr_const64"; "expr_eq" -> "expr_cond"; "expr_eq" -> "expr_eq"; "expr_eq" -> "next"; "expr_land" -> "expr_landor"; "expr_land" -> "expr_or"; "expr_landor" -> "expr_land"; "expr_landor" -> "expr_or"; "expr_landor" -> "next"; "expr_lor" -> "expr_land"; "expr_lor" -> "expr_landor"; "expr_or" -> "expr_xor"; "expr_or" -> "next"; "expr_preprocess" -> "expr_const"; "expr_preprocess" -> "next"; "expr_preprocess" -> "next_nomacro"; "expr_prod" -> "next"; "expr_prod" -> "unary"; "expr_shift" -> "expr_sum"; "expr_shift" -> "next"; "expr_sum" -> "expr_prod"; "expr_sum" -> "next"; "expr_type" -> "expr_eq"; "expr_type" -> "gexpr"; "expr_type" -> "unary"; "expr_xor" -> "expr_and"; "expr_xor" -> "next"; "find_field" -> "find_field"; "force_charshort_cast" -> "gen_cast_s"; "gbound_args" -> "gbound"; "gb
Re: [Tinycc-devel] Modifying a char pointer initialized by character string literal should cause an error.
Hi, On Fri, Dec 27, 2019 at 10:26:24PM +0800, 瞿兴 wrote: > In section 6.7.8 of the C99 draft document defines : > > If an attempt is made to use pointer variable p to modify the contents of the > array, the behavior is undefined. > > When executing the testcase(in the attachment), tinyc does not report an > error and modify the value of the variable NISLParameter0 successfully Well, "undefined behavior" allows tinycc to do this. > The attachment includes the relevant testcase. IMHO the only thing tinycc should do is to warn that a const char * has been implicitly cast to char * in the initialization of NISLParameter0. Putting string literals into read-only sections is a nice to have. > char *NISLParameter0 = "abcdefghij"; Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] make tcc reentrant
Hi, On Sat, Dec 07, 2019 at 11:34:11AM +0100, Ulrich Schmidt wrote: > - The in scenario1 unloved 1 function parameter can be ignored and the > values stored locally: > #define LIBPARAM1 > #define VALUE(v) v > .. > > somereturn somefunc(LIBPARAM1 ...) { > VALUE(count) = 0; > ... > > - in scenario 2 we define the 2 macros different: > #define LIBPARAM1 TCCState *s1, > #define VALUE(v) s1->v We need a macro #if scenario == 1 #define PASSPARAM1 #else #define PASSPARAM1 s1, #endif Grouping all globals in the TCCState structure might be beneficial even if we don't switch to those macros, because of the cache locality Christian wrote about. The VALUE macro in scenario 1 would then be #define VALUE(v) global_state.v Btw, has anyone thought about handling TCCState like the context is handled in the OpenGL API? It has one function to select the context to use for following operations and the operations themselves don't have a parameter for the context. If the pointer to the TCCState is stored in a normal or in a TLS variable is up to us and might even be a compile time option (that is set to "normal" for compilation with tcc as long as tcc doesn't know how to generate TLS variables). Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] How do I disable all runtime error checks
On Mon, May 20, 2019 at 01:08:32PM -0700, Ben Hutchinson wrote: > I've > never had any problem with programs I've written in assembly regarding the > stack. Have these been PE Windows applications and have they ever tried to increased the size of the stack by more than 4096 bytes? Best regards Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tinycc-devel Digest, Vol 192, Issue 11
On Sat, May 18, 2019 at 10:45:32AM -0700, Ben Hutchinson wrote: > It requires > MinGW to run in Windows (I'm a Windows user), so that means that using GCC > by itself is simply not an option, because it won't run without its MinGW > dependencies. The whole point of MinGW is that it uses the C library that is shipped with Windows. > This makes GCC very bloated (over 100MB in size), and thus > not a viable alternative to TCC. Just compare that to the size of your printer driver. Or the size of your hard disk... And precompiled GCC binaries usually also contain compiler backends and libraries for languages like C++, Objective C, Fortran and Ada. > Also, what is this "ONE_SOURCE=yes" > command line option you talk about in GCC? ONE_SOURCE is a macro in the TinyCC source code. It causes all C files to be compiled as one huge chunk, allowing the compiler optimize a bit more. > The simple solution would be for you (or another developer of TCC) to just > add a command line switch that when used causes TCC to not use the __stkchk > function, and thus remove the requirement for this function to exist, and > also prevent TCC from adding any extra code to the program's main code to > call this function. Let me repeat: Code running on Windows might crash if this function is not called where TinyCC emits a call to it. If you don't need __chkstk, you are not compiling for Windows and should not use a TinyCC that is targetting Windows. TinyCC targetting Linux does not emit calls to __chkstk. On the other hand, you appear to be able to understand C, so it should be easy for you to delete the eight lines from x86_64-gen.c and recompile TinyCC. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] How do I disable all runtime error checks
On Thu, May 16, 2019 at 04:09:51PM -0700, Ben Hutchinson wrote: > The only reason I don't > use GCC is that overall it is worse at generating bloated code, No, try gcc -Os textdata bss dec hex filename 302619 30888 149624 483131 75f3b tcc built with tcc and defaults 290108 30440 149720 470268 72cfc tcc built with tcc and ONE_SOURCE 2467271244 149768 397739 611ab tcc built with gcc 8.2 and defaults 1771051236 149768 328109 501ad tcc built with gcc -Os instead of -O2 1725361228 149760 323524 4efc4 tcc built with gcc -Os and ONE_SOURCE The tcc built with gcc -Os ONE_SOURCE=yes is also about 43% faster on my Atom 330 at compiling and linking itself (0.37s vs. 0.65s, median of 51 runs). Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] How do I disable all runtime error checks in TCC?
On Wed, May 15, 2019 at 03:50:06PM -0700, Ben Hutchinson wrote: > I would like to make it so it doesn't insert ANY error checking code such > as stack checks, etc, into my program's code. You can tell if it is doing a > stack check because if you use -nostdlib, you can compile some very simple > programs, but if you try more complex programs it will give you the error: > tcc: error: undefined symbol '__chkstk' __chkstk is not for error checking. __chkstk is needed on Windows when the stack frame of a function exceeds 4 kB, because Windows allows the stack to grow only one page at a time. So __chkstk just touches all stack pages needed by the function in the correct order. If you are confident that you don't need __chkstk, you can provide your own dummy implementation. Best regards Daniel ___ 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&double 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
Re: [Tinycc-devel] Porting tcc to Xtensa and running it on the ESP32
Hello Lars, On Thu, Feb 14, 2019 at 05:39:06PM +0100, Lars Hochstetter wrote: > I (newbie) was wondering how difficult it would be to > > 1. port tcc to the Tensilica Xtensa platform one difficulty is that Xtensa processors are very configurable. When someone synthesizes an Xtensa processor, the Tensilica tools generate a bunch of C header files that tell you f.ex. which instructions are enabled, which coprocessors exist and how many registers there are. You might remember that it took some time for GCC to be ported to the ESP8266. That was because it uses the uncommon call0 ABI variant as Espressif did not enable register windows (XCHAL_HAVE_WINDOWS == 0). But if you stick to the ESP32 and don't want to support all Xtensa variants, this should not be a problem. > Point 4 sounds pretty ambiguous - I don't know if I should use the > FreeRTOS port for the ESP32 (tcc could run as a FreeRTOS task and > receive input through e.g. the serial interface) or use an > bare-metal approach. I don't see where FreeRTOS would help you with tcc. Last time I checked, FreeRTOS was only about task management and IPC. On the other hand it takes just a few lines of code to put a bare metal program that does not access peripherals into a FreeRTOS task. RAM might become a problem. I have no idea how much RAM tcc needs. You might want to do some experiments with valgrind --tool=massif before trying to run it on the ESP32. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TinyCC for bootstrapping (with patches)
On Sun, Jan 13, 2019 at 05:02:38PM +0100, Giovanni Mascellani wrote: > 2) I patched TinyCC so that it can be built by a compiler that does not > support floating point numbers (as is the case for the C compiler in > asmc that builds TinyCC). Basically I import in the TinyCC repository > the code from the Berkeley SoftFloat library[3] and replace each > operation between floating point numbers with the corresponding call to > SoftFloati. I really like the idea of using a library to perform floating point operations and I also like that you made it optional. But it looks like you made the assumption that long double is an 80 bit floating point type. This is only true for x86-32. You have to look at the LDOUBLE_SIZE macro to determine which of float64_t, extFloat80_t, and float128_t to use (For x86-32 it is 12 instead of 10 because of padding). Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tcc doesn't work on OSX unless used via -run which isn't sufficient for most use cases
Hi, On Sun, Jan 06, 2019 at 07:33:15PM -0800, Timothee Cour wrote: > not appearing in > http://lists.nongnu.org/archive/html/tinycc-devel/2019-01/index.html I got your first mail. Maybe the mail archive is updated every few hours. > so I'm following up here: https://github.com/TinyCC/tinycc/issues/8 > (would rather use github issues if possible, but if you guys prefer > mailing list, fine too) This is an unofficial mirror of the code. I wonder why Vladimir allows Github issues to be created if he does not react to them. > > Is there any plan on supporting OSX? The situation is still the same. OS X uses a completely different file format for its object files and nobody has stepped up to implement it. Do you maybe want to implement it? Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] When is planned to be released the next version of Tcc?
On Sun, Dec 23, 2018 at 11:44:50AM +0100, Barath Aron wrote: > I traced the whole object loading procedure with gdb: > - ARM_EXIDX (section 6) is definitely not loaded, I traced it with gdb. Where did tcc decide to skip ARM_EXIDX? ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Commit 'x86-64: Fix calls via absolute function pointers' makes 07 test fail on ARM
On Sat, Dec 22, 2018 at 11:50:46AM +0100, Daniel Glöckner wrote: > GCC generates a "veener" Of course it's the linker, which is separate from GCC. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Commit 'x86-64: Fix calls via absolute function pointers' makes 07 test fail on ARM
On Thu, Dec 20, 2018 at 08:48:17AM +0100, Christian Jullien wrote: > * At least on ARM (like RPi), zfunc below fails with something like: > * +tcc: error: can't relocate value at 1ef93bc,1 > void zfunc() > { >((void (*)(void))0) (); > } The issue is that TCC does not know how to encode an absolute address in the BL instruction. BL is always a relative call within +/- 32MB. GCC generates a "veener" (aka trampoline) during linking if the link target turns out to be outside of this range. For calls to absolute addresses this is "LDR PC, [PC, #-4]" followed by the address. We might also have this problem when we have to link a binary with a .text section bigger than 32 MB. We could use the same veener in that case, but if we aim for position independent code, we need one more instruction: "LDR IP, [PC] ; ADD PC, PC, IP ; .word target - 0f ; 0:" I have not looked at the code, but I believe it will be difficult to insert the veeners between sections after the linker has made a plan at which address to place the sections. We might also need several iterations since adding veeners might increase the distance for calls or branches beyond 32MB that were barely within 32MB without veeners. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Build libpng with tcc
On Thu, Jul 12, 2018 at 08:46:54PM +0300, Evgeny Nikonov wrote: > PNGCBAPI is _cdecl or __stdcall > What's wrong? _mingw.h contains only a definition for __cdecl, not for _cdecl. And I guess you either didn't try __stdcall or _mingw.h is not included. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Joining Tiny C Compiler with ItsyBitsy M0 Express
Hello Ulrich, On Fri, Apr 20, 2018 at 06:45:28PM +0200, Ulrich Althöfer wrote: > is it possible to implement the TCC on an awsome microcontroller board? in theory yes, but right now TCC does not support the Thumb instruction set used by Cortex-M ARM cores. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] backtrace() on Linux
Hi Yakov, backtrace() from Glibc calls _Unwind_Backtrace from libgcc_s.so.1 on x86_64. Guess which compiler libgcc_s.so.1 is made for. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Basic register usage
On Tue, Sep 26, 2017 at 07:59:30PM -0400, Charles Lohr wrote: > Is there some way of hinting to TCC "hey, register X contains Y sym" What > functions/data structures would I use in func_prolog to tell TCC about it? No, the gfunc_prolog function in all existing backends stores all parameters that are passed in registers on the stack. The offset in the stack frame is remembered together with the name of the parameter. Remember, TinyCC forgets what is inside the registers after each statement. So after the prolog has been emitted, all parameters must be on the stack. On the other hand, the gfunc_call function will get the parameters on the vtop stack. The r element of each vtop element will tell you if the value is already in a register and which register it is. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Resources/questions for porting?
Forgive me the brevity of my reply, but I should be asleep right now. On Mon, Sep 25, 2017 at 09:16:12PM -0400, Charles Lohr wrote: > To do this, I need to port TCC to xtensa specifically lx6 with no floating > point. It won't be easy to support floating point without floating point registers. TinyCC is not prepared to keep floating point values in integer registers. And you will need a soft float library like libgcc that probably can't be built with TinyCC unless you also implement an assembler. > (1) How does one get involved in coding for the core of TinyCC? Usually by submitting patches. > (2) I could use a C-to-JS compiler for this project. If I did succeed and > it worked well, would you consider it for inclusion considering emscripten > is a bloated mess. If you write it anyway, you might as well ask for inclusion. We keep these C67 and IL backends around, even though I have never heard of anyone using them. > (3) If I do get this xtensa output working, would there be interest for > inclusion in mainline? I'd say yes. > (4) Is there a better community (chat/discord/etc.) for discussing tinyCC? No, this is the best place. > (5) Currently, I am working by pulling from the repo.or.cz and pusing to my > git branch. Is this a reasonable thing to do before I am ready to try to > get into mob? Yes, it is. Please post the patches to the mailing list first. People pushing controverse patches to the mob branch has caused bad blood on the mailing list several times in the past. > (6) An in-depth discussion of what all goes into the -gen and -link files? > I think I've got it mostly figured out with the definitions in > xxx-[link|gen].c in tcc.h. I don't believe there is any documentation. When I wrote the ARM backend, I tried to mimic what the i386 code did. > (7) Register assignments. When I write my prolog and see code generation > requests, they seem to do some very dumb things almost assuming I have zero > registers. I don't understand how the management is supposed to work. It > feels rather muttled. I saw register assignment help in the ARM port, but, > it felt integrally tied into TCC in ways that are difficult to mirror for > xtensa. TinyCC forgets what is inside the registers as soon as it has emitted the code for a statement. There is no optimization across statements (which simplifies creating test cases for bugs btw.). > (8) Rationales behind emitting code directly from the -gen, -link. I.e. > Has anyone ever done a video or presentation on the big WHY. It feels VERY > different from other compilers in that it seems almost directly geared away > from having multiple steps. Which, is fast. But... may be suboptimal? It was done to have a small compiler. TinyCC was born as an IOCCC submission. > (9) Anything that discusses how optimization really goes on. Or is TCC's > approach always "you write slow C code, you get slow C code." It is mostly like that. There is a litte optimization inside expressions and someone once wrote code to not emit dead if/else branches (Did that code get merged?), but that's all that comes to mind right now. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Crutches_for_TCC_inline_Asm
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
Re: [Tinycc-devel] Inline assembler
Hi, On Thu, Jul 13, 2017 at 07:19:30AM +0300, ANDY TAKKER wrote: > 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? TCC uses the GCC way of passing parameters to inline assembler. See https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Annoying new warning
On Sat, Apr 29, 2017 at 07:55:18PM +0200, Michael Matz wrote: > ARMs long double > type simply is double itself, and hence these functions are unused > on ARM. Well, they would be if there wouldn't be strange code in > arm-gen.c that makes use of xfdi conversions when VFP is enabled. > That makes no sense, also with VFP there's only support for IEEE > double, not for extended double. Since LDOUBLE_SIZE == 8 on VFP, those code lines will only be used with FPA. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Ready for Release 0.9.27
On Thu, Feb 09, 2017 at 01:35:31PM +0100, Vincent Lefevre wrote: > If an int can represent all values of the original type (as > restricted by the width, for a bit-field), the value is converted > to an int; otherwise, it is converted to an unsigned int. These are > called the integer promotions.58) All other types are unchanged by > the integer promotions. I've had a look at the code. We can easily change gv() to cast unsigned bitfields < 32 bits to signed int, but there are lots of places where the code just looks at the VT_UNSIGNED flag or the VT_LLONG basic type and doesn't notice that VT_BITFIELD is set as well (and the size is < 32 bits). Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Weird bitfield size handling, discrepancy with gcc
On Tue, Oct 18, 2016 at 09:41:49AM +0200, Vincent Lefevre wrote: > AFAIK, both are correct. It depends on the ABI. The ARM EABI defines those details in http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042f/IHI0042F_aapcs.pdf section 7.1.7. But I don't know if we adhere to those rules when compiling for ARM. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Governance (Re: cleanups)
Hi, on Github we could use Travis to run tests after every commit. We could also use Qemu there to check if the other architectures still work. It might also serve as an example how to setup a cross development environment with TinyCC. Best regards. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Use TCC with GSL under Windows
Hi Xianwen, On Tue, Oct 11, 2016 at 11:43:40PM +0200, Chen, Xianwen wrote: > I have been very impressed by the size of exe's that TCC produces in > Windows. For the simple hello_world.c, TCC produces an exe of 2 KB, while > mingw-w64 produces an exe of 164 KB. Therefore, I would like to continue to > learn to use TCC. I'm pretty sure I've used MinGW to generate executables that small, although that was probably 16 years ago. Try to pass -s to GCC and don't use -g to get rid of symbol tables and debugging information. Most of the time TCC generates more code than GCC, especially when GCC is called with -Os. The linker of MinGW might enforce different section alignments than TCC. But that should add less than 10 kB of padding, regardless of the code size. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] ARM32 gfunc_epilog
On Mon, Oct 10, 2016 at 11:46:41AM +0200, Daniel Glöckner wrote: > It emits the instruction "ldm fp, {fp, sp, pc}" which AFAIK will not > do what we want when it is restarted after an exception, as the first > thing it does is to change fp. After reading all those ARM docs, I get the feeling that this will not affect us. All existing Cortex-A processors do not support interruptible LDM/STM as per ID_ISAR2 register and since ARM7EJ-S data aborts use the base restored data abort model, meaning they restore the base register to the value it had before the instruction. I have to check what my Zaurus does. It still uses the base updated data abort model. The old APCS standard apparently also used "ldmdb fp, {fp, sp, pc}", so it would have suffered from the same problem. The ARM11 (RPi!) does indicate support for interruptible LDM/STM in its ID_ISAR2, but it will not interrupt these instructions unless low interrupt latency mode is enabled. ARM11 was the first ARM with low interrupt latency mode. I somehow doubt that Linux can run in this mode. Generating APCS-compatible stack frames that can be unwound f.ex. by the Linux OProfile code is easy. Creating the .ARM.extab and .ARM.exidx sections specified by EABI would be significantly more work. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] ARM32 gfunc_epilog
Hi, I think we need to change the epilog used on ARM. It emits the instruction "ldm fp, {fp, sp, pc}" which AFAIK will not do what we want when it is restarted after an exception, as the first thing it does is to change fp. A workaround would be to move fp to lr first and use that to load the other registers. There once was a discussion about aligning our stack frame with the one expected by debuggers. Maybe it is time to do that. Any suggestions? Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] PATCH: In gen_vla_sp_restore, use X30 rather than get_reg.
On Mon, Oct 10, 2016 at 10:19:24AM +0200, Daniel Glöckner wrote: > On Sun, Oct 09, 2016 at 11:51:11PM +0100, Edmund Grimley Evans wrote: > > -uint32_t r = intr(get_reg(RC_INT)); > > +// Use x30 because this function can be called when there > > +// is a live return value in x0 but there is nothing on > > +// the value stack to prevent get_reg from returning x0. > > +uint32_t r = 30; > > Wait, can this happen on ARM32 as well? Why is x0 still in use? Never mind, I was mentally inside gen_vla_alloc(). My gen_vla_sp_restore() just calls load(), which will use r14 if it needs a temporary register and usually doesn't need one (unless the current stack frame is > 4 kB). Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] PATCH: In gen_vla_sp_restore, use X30 rather than get_reg.
On Sun, Oct 09, 2016 at 11:51:11PM +0100, Edmund Grimley Evans wrote: > -uint32_t r = intr(get_reg(RC_INT)); > +// Use x30 because this function can be called when there > +// is a live return value in x0 but there is nothing on > +// the value stack to prevent get_reg from returning x0. > +uint32_t r = 30; Wait, can this happen on ARM32 as well? Why is x0 still in use? Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] BUG for ARM (32) maintainers
On Sat, Oct 08, 2016 at 07:33:03PM +0200, Christian Jullien wrote: > Now, the only two broken tests are related to unsupported vla: VLAs are now supported on ARM. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] BUG for ARM (32) maintainers
On Sat, Oct 08, 2016 at 02:13:54PM +0200, Christian Jullien wrote: > I don't know if you are aware, but for uncounted months, 73_arm64 is broken > on ARM (as with mi RPi which uses Hard floats). Try again. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] cleanups (Incorrect function call code on ARMv6)
On Mon, Oct 03, 2016 at 12:48:00PM +0200, grischka wrote: > Ok, have seen it: crash in "make test". So it's long long *p, v; p = &v; p[0]++; that is miscompiled without the save_regs. To load the upper half of p[0] 4 is added to the register that holds p. But the register may not be modified because it is still used further down on vtop to store the incremented value. So actually we just have to save all entries on vtop that use the same register as the topmost one. We could also use a fresh register for the address of the upper half instead. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] cleanups
Hi, On Sat, Oct 01, 2016 at 09:03:47PM +0200, grischka wrote: > I did push some cleanups to prepare for a release 0.9.27, > eventually. Just if you wonder what's the point of that. I'd vote for applying Balazs' patches from August 25 ("Incorrect function call code on ARMv6") before the release. Unless of course someone can prove that the second patch breaks something. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Incorrect function call code on ARMv6
On Thu, Aug 25, 2016 at 10:06:51AM +0100, Balazs Kezes wrote: > On 2016-08-11 09:24 +0100, Balazs Kezes wrote: > > I think it's just that that copy_params() never restores the spilled > > registers. Maybe it needs some extra code at the end to see if any > > parameters have been spilled to stack and then restore them? > > I've spent some time on this and I've found an alternative solution. > Although I'm not entirely sure about it but I've attached a patch > nevertheless. > --- a/tccgen.c > +++ b/tccgen.c > @@ -854,11 +854,6 @@ ST_FUNC int gv(int rc) > #endif > if (r >= VT_CONST || /* XXX: test to VT_CONST incorrect ? */ > (vtop->r & VT_LVAL)) { > -/* We do not want to modifier the long long > - pointer here, so the safest (and less > - efficient) is to save all the other registers > - in the stack. XXX: totally inefficient. */ > -save_regs(1); > /* load from memory */ > vtop->type.t = load_type; > load(r, vtop); This save_regs was added by Fabrice in October 2004 with the commit message "fixed long long code gen bug". He didn't add a test case and I couldn't find a mail related to this problem in the year before the fix was committed. I'd say we should apply your patch and wait for someone to hit the original problem again. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Incorrect function call code on ARMv6
On Wed, Aug 10, 2016 at 06:59:46AM +0100, Balazs Kezes wrote: > 90: e5912000ldr r2, [r1] ; <-- This is the y argument. > 94: e50b2018str r2, [fp, #-24] > 98: e5901000ldr r1, [r0] > 9c: e284add r0, r0, #4 > a0: e5902000ldr r2, [r0] ; <-- The clobbering happens here. > a4: e50b101cstr r1, [fp, #-28] > a8: e1a01002mov r1, r2 > ac: e51b001cldr r0, [fp, #-28] > b0: ebfebl 0 I think the error is caused by the "vtop--;" lines in copy_params(). The former gfunc_call() implementation for ARM rotated the elements on the parameter stack to let get_reg() know that the registers are still in use. The current implementation drops each element directly after it has been moved to the final register. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] MAJOR bug: tcc doesn't detect duplicate cases in switch statements
On Sat, Mar 12, 2016 at 10:58:42AM -0700, arn...@skeeve.com wrote: > The bug caused me to push bad code to gawk's repo. It's only luck that it > wasn't noticed, but a bug is a bug. So you have personal feelings towards that bug. I'd never use TinyCC for serious development. There are simply not enough testers. > The issue isn't just the lack of diagnostic - what kind of erroneous > code is being generated in this case? Let's see what the final C11 draft (N1570) says about this issue: Section 6.8.4.2 paragraph 3: The expression of each case label shall be an integer constant expression and no two of the case constant expressions in the same switch statement shall have the same value after conversion. Section 4 paragraph 2: If a "shall" or "shall not" requirement that appears outside of a constraint or runtime-constraint is violated, the behavior is undefined. There you read it, C11 allows us to generate whatever we want. Regarding the cost of your solution, a tree structure might be faster and could also be implemented in a way that handles value ranges. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] License is too restrictive for real-world use.
On Wed, Mar 02, 2016 at 11:01:04AM +, John B wrote: > Also I was hoping maybe a previous version of it that didn't include > as many devs on-boarding from the 2013 version could be changed. Thus > nulling out the sign-off on devs that came afterwards. My first contribution was merged in 2003 if you are looking for older versions. > Because bsd license I believe would be 100x healthier for the project. It sounded like you wanted to keep it a secret in your product that is would be based on TinyCC. That is in violation of the second clause of the BSD license. The MIT license has a similar clause (actually it is more similar to the first BSD clause but not restricted to source code). > People would absolutely contribute back, but in a de-identified way. > I Absolutely believe this. So you would contribute back everything if it was BSD? What do you mean by "de-identified"? Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] License is too restrictive for real-world use.
On Wed, Mar 02, 2016 at 08:38:45AM +, John B wrote: > I love playing around with toys and trying to make them better. It beats > sudoku. But I am not going to surreptitiously steal the software but on > the cooperative flip side of that coin, I don't want to release my code, > either. After reading your side of the story, I have the feeling that keeping my parts of TinyCC as LGPL was the right choice. TinyCC is a small project with very few active developers. If your product uses TinyCC, you should feel the responsibility of committing improvements you made back the main project. (If on the other hand your product consists mainly of a modified version of TinyCC, you can try to convince us by offering a share of your earnings. ;) Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] You can use __declspec in TCC?
On Tue, Jan 12, 2016 at 02:38:50PM -0800, Ben Hutchinson wrote: > Also, I thought that to make it stdcall, you > needed to use __attributes__((stdcall)), not a standalone __stdcall. These > are the "weird" things that set TCC apart from all other C compilers I > thought, yet you say these C compiler standards also work in TCC? > > And by the way, I think __stdcall (with 2 underscores) for setting the use > of STDCALL calling convention is a Microsoft thing (as used in VC++). The > official C standard for setting the use of STDCALL calling convention is > actually supposed to be _stdcall (with 1 underscore). Isn't that correct? stdcall is a Microsoft thing. What are these C compiler standards you are talking about? AFAIK there are no standards for stdcall, only conventions. In a time before Cygwin and MinGW GCC did not know about stdcall. As GCC already had some other __attribute__((somethings)) they implemented stdcall as another function attribute instead of adding a new keyword. To get the Microsoft keyword #define __stdcall __attribute__((stdcall)) __stdcall has two underscores because the C standard (the real standard) says that all names that begin with two underscores are reserved, meaning you're on your own if there are name clashes when your code introduces a variable, function, or macro with the same name. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Source vandalism
On Wed, Jul 29, 2015 at 08:56:47AM -0400, gus knight wrote: > The reformattings were to attempt to make everything conform to the > "CodingGuidelines" document that was already in the tree (4 spaces not > tabs, etc.) which a few files didn't conform to. The CodingStyle document is from April. Most code predates that file and I can't remember any discussion about the coding style on this list. The document merely lists what has been found while looking at several files. > Yes, I will. Apologies, I should've looked more closely (or run the > whole thing through clang-format, but that probably would've done > damage in a different way...) If you use clang-format again, please don't change "char *x" to "char* x". Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] mob: alloca-arm.S:1: error: unrecognized file type on RPi
On Sun, Mar 08, 2015 at 11:02:18AM +0100, Christian JULLIEN wrote: > ../tcc -B.. -c alloca-arm.S -o arm/alloca-arm.o -I.. -Wall -g -O2 > -Wno-deprecated-declarations -Wno-strict-aliasing -Wno-pointer-sign > -Wno-sign-compare -Wno-unused-result -Wno-uninitialized -fno-strict-aliasing > -fPIC -DTCC_TARGET_ARM > alloca-arm.S:1: error: unrecognized file type There is no ARM assembler in TinyCC. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Is this a duplicate ASM operation?
On Sun, Jan 18, 2015 at 02:10:52PM +0800, YX Hao wrote: > I don't know much about ASM and how tcc translates c code into ASM. > If the 2nd MOV is not necessary, can we optimize it in tcc? The redundant instruction is from the following printf call. TinyCC does not remember what is in each register when it starts to compile the next C statement. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] sinf/sin problems
Hi, just some nit-picking: On Wed, Dec 24, 2014 at 04:46:14PM +0800, Lee Duhem wrote: > `sinf' is defined in libm.so, you need to link with it. on Linux > As explained by Aharon, c compiler will offer an implicit declaration > for any undeclared function that it saw, and the return type of this > implicit declaration is `int'. Therefore those return values of `sin' > in your code will be converted to `int' first, then convert to `double' > for `printf' to print. The return value of a function returning an int is not passed in the register where a double would be returned, so you might get garbage that is in no way related to the input. On top of that the int is not cast to double in printf("\n%f", sin(1.0)); The bytes on the stack are simply reinterpreted as double, so printf("%f\n", 1); will not print 1.00. That's because of the ellipsis in the declaration of printf. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TCC as default compiler
On Tue, Dec 09, 2014 at 01:19:55AM -0500, stephen Turner wrote: > I have found tcc and wondered how viable it is as a alternative to gcc and > clang/llvm for my uses. What is your motivation to switch away from gcc/clang? The benefits of TinyCC are smaller and faster compiler but it is by far less tested and only does minor optimizations. > Does it use makefiles? It's a compiler, not a development environment. Or are you asking if the compiler is built using makefiles? > can it be a simple drop in replacement for GCC (atleast for c if not c++ > too) For simple code, yes. > From what i have read so far its only a c compiler? Or is it being built > out to support c++ as well? IIRC there have been some attempts at adding various aspects of C++ into TinyCC, but none of them have been merged back into the main repository. There is a recent discussion to use the CFront C++ to C translator with TinyCC. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] How to use char "\"
Hi, On Wed, Oct 01, 2014 at 12:06:24AM +0800, Thomas Preud'homme wrote: > > I have a problem with the char "\". For example in the line: > > > > strpbrk (file_name,"\*?") > > > > ir order to know if i have a simple file name, tcc tells me "unknown > > escape sequence". > > The manpage doesn't say that the strings accept escape sequence. Is it even > defined in the standard? Sounds like a bug in TinyCC. Thomas, C does support the escape sequences \a, \b, \f, \n, \r, \t, \v, \', \", \?, \\, \<3octal>, \x<2hex>, \u<4hex>, and \U<8hex>. I guess BCC probably interpreted \* as \\*. > > When I want use as a char both text[i]='\' and text[i]='\\' do not > > work. Since I am there working on text strings I cannot equate '\' to > > ascii 28 first. > > '\' should be correct. What is the error you get? '\\' should be correct. What is the error you get? Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Building Unicode applications with TCC in Windows.
On Sat, Jul 05, 2014 at 10:09:34PM +0800, YX Hao wrote: > > Is is expected or is there something wrong? Would it be possible to make a > > modification to enable wmain() to be an entry point as well as main()? > > Maybe you can take a look at: > win32\lib\crt1.c In crt1.c declare main and wmain as weak. In _start call __getmainargs/main if main and __wgetmainargs/wmain if !main. I wonder if this works when linking to static libraries like libfl (from GNU flex) that contain a main function. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Is static linking functional?
On Mon, Jun 23, 2014 at 12:07:45PM -0700, Wendell P wrote: > I'll admit I'm confused by the operation of the "-static" switch in TCC. > > tcc app.c lib.a Links a single static library > tcc -static app.c lib.a Instructs TinyCC to use only static libraries, even for implicitly linked libraries like msvcrt. I doubt you can create anything useful in Windows without dynamic libraries. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] run vs compiling
On Sat, Jun 21, 2014 at 04:25:24PM +0200, Markus Bergholz wrote: > Yes, this works. But why tcc don't need the -lm option when using -run? Because tcc itself is already linked to libm. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] run vs compiling
On Sat, Jun 21, 2014 at 03:44:27PM +0200, Markus Bergholz wrote: > ~$ tcc *[^ca].c lgc.c lfunc.c -run lua.c > Lua 5.2.3 Copyright (C) 1994-2013 Lua.org, PUC-Rio > > > > > So far so good, but how can I compile/create binarys with tcc from lua? > > ~$ tcc *[^ca].c lgc.c lfunc.c > tcc: error: undefined symbol 'main' > tcc: error: undefined symbol 'fabs' ... How about ~$ tcc *[^ca].c lgc.c lfunc.c lua.c -lm -o lua ? ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tinycc from git still can't compile fossil-scm
On Sun, Mar 30, 2014 at 04:10:48PM +0100, Domingo Alvarez Duarte wrote: > I followed the code on fossil-scm with printfs on va_start/va_end using the > previous tcc stdargs implementation and it showed me that both the parent > and child do va_end on the same pointer that's why the segfault. As long as fossil-scm uses fork and not vfork, calling va_end in the parent and child can't be the reason for the segfault. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tinycc from git still can't compile fossil-scm
On Sat, Mar 29, 2014 at 11:52:42PM +0100, Daniel Glöckner wrote: > Or simply > > typedef struct __va_list_struct va_list[1]; Fixed in mob. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tinycc from git still can't compile fossil-scm
On Sat, Mar 29, 2014 at 11:46:26PM +0100, Daniel Glöckner wrote: > Actually sizeof(va_list) is 24 on x86_64 GCC although va_list is passed > as a pointer. So we should > > typedef void *va_list[3]; Or simply typedef struct __va_list_struct va_list[1]; ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tinycc from git still can't compile fossil-scm
> Errr. I see you now fiddled with that on mob. Commit c025478d7c03, > rewriting va* to not use malloc. That's completely wrong. You've > effectively changed the ABI of stdarg, and hence interoperability > with every non-TCC compiler. The public va_list on x86_64 _must_ be > a pointer. Actually sizeof(va_list) is 24 on x86_64 GCC although va_list is passed as a pointer. So we should typedef void *va_list[3]; and cast that to struct __va_list_struct as needed. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Valgrind Inconsistency detected by ld.so: rtld.c:
On Fri, Mar 28, 2014 at 12:27:39PM +, Domingo Alvarez Duarte wrote: > For arm experts, it gets a segfault on translate.c:98 Please try again with current mob. I fixed a bug that might be the cause for your segfault. Best regards, Daniel P.S.: I wonder if a better fix would be to use convert_parameter_type in gfunc_param_typed. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Why memcpy is imported ?
On Fri, Feb 21, 2014 at 04:06:12AM -0300, Carlos Montiers wrote: > with calling to SetConsoleCursorPosition a import for memcpy of > msvcrt.dll is created, without SetConsoleCursorPosition the memcpy import > is not there. > > Why memcpy is imported if I not use it in the code? Because you pass a structure by value. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Drop OABI and FPA from arm-gen.c
Hi Thomas, On Mon, Feb 10, 2014 at 10:22:03PM +0800, Thomas Preudhomme wrote: > No new hardware come with a FPA unit as far as I know and > kernel FPA implementation was removed from the Linux kernel a few > versions ago. Russel King wanted to remove the NWFPE emulator in April 2013 because of licensing issues, but Linus overruled him. It is still available in 3.14-rc2. > Also you might yourself have some hardware > or installation with them I do still have the SL-5500 that I used back then to develop the TinyCC ARM backend, but the only thing I do with it these days is to recharge the battery. I suppose that doesn't change your mind, does it? How about a big fat warning to users of ARM OABI in 0.9.27 before it is removed once and for all an 0.9.28? Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Recent change breaks test3 on RPi
Hi Thomas, On Wed, Feb 05, 2014 at 02:15:07PM +0800, Thomas Preud'homme wrote: > I would like to fix this but I need to see first why tcc and gcc differ. > Daniel, if you read this, can you explain me why gcc seems to use a signed > char while tcc uses an unsigned char? it seems char, signed char, and unsigned char are distinct types in C. With GCC neither unsigned char nor signed char is compatible with char. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] uint64_t/int64_t => double broken on ARM
Hello Thomas, On Sat, Feb 01, 2014 at 07:04:24PM +0800, Thomas Preud'homme wrote: > Got a bit of time (and more importantly internet access) so it's now > fixed in mob. Thanks for reporting. your patch makes float f(unsigned long long x) { return x; } compile to ... bl __aeabi_ul2f vmovs0, r0 vmov.32 d0[0], r0 vmov.32 d0[1], r1 ... with softfp ABI and it generates the superfluous move from r1 with hard float ABI. Maybe the cleanest solution is to temporarily change the ABI when calling these functions. Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] uint64_t/int64_t => double broken on ARM
On Tue, Jan 28, 2014 at 06:51:53AM +0100, Christian Jullien wrote: > Playing with clock_gettime and uint64_t/int64_t on RPi (ARM), I discovered > uint64_t => double conversion bug : > > NOTE: tcc is compiled using --with-libgcc The problem is that the EABI functions provided by libgcc still expect and return doubles in integer registers, even on hardfloat systems. This also affects casts in the other direction. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] linking tinycc
Hi Christian, On Sat, Jan 04, 2014 at 10:46:15AM +0100, Christian Jullien wrote: > If I understand you well, you want to change RELICENSING file > From > Daniel Glöckner? arm-gen.c > To > Daniel GlöcknerNO arm-gen.c done. > What can we do if > we want an ARM backend having BSD Like license? > - rewrite from scratch > - dual license (either LGPL or BSD Like). I know many projects having dual > license. > - you allow tcc projet to make a fork, arm-gen.c -> arm-bsd-gen.c (and maybe > ./configure choose one or the other --bsd-only for example) Dual licensing defeats the purpose of not agreeing to the relicensing. It would be meaningful only if there were projects shipping modified versions of TinyCC that drop the BSD license in favor of the LGPL and that are more interesting to use as a base for new projects than TinyCC itself. Forking a BSD version is only useful if the BSD version initially contains less features, f.ex. by relicensing an old version of that file. I don't like playing those games. As for rewriting that file, I think Thomas is doing a good job at achieving that. Of the 2101 lines in that file git blame marks 525 lines as having been modified by him. > Do you see other possible solution, what do you advice? Another possibility is that I might change my mind in the future. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] linking tinycc
On Sat, Jan 04, 2014 at 10:08:09AM +0800, Thomas Preud'homme wrote: > I don't think law has determined whether copyright is per file or more > fined grained but it shouldn't make a big difference in the case of tcc. > Files > are usually mainly contributed by 1 or 2 big contributors and the rest are > small patches that probably don't have copyright on their own (IANAL though). FWIW I'm fine with relicensing all my contributions to files other than arm-gen.c to the BSD license reproduced in RELICENSING. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] float value triggers error
On Sun, Nov 03, 2013 at 12:09:32PM -0800, Steven G. Messervey wrote: > mob-branch, configured with "--with-libgcc" only, debian squeeze 32-bit: > tcc: error: undefined symbol '__tcc_fpinit' > tcc: error: undefined symbol '__tcc_cvt_ftol' --with-libgcc uses libgcc instead of libtcc1. This will of course fail for tcc specific functions. __tcc_cvt_ftol does the same as libgcc's __fix{s,d,x}fdi and there are already tokens defined for those functions for use on ARM. The only difference is that __tcc_cvt_ftol passes the floating point value in a register and therefore does not have to distinguish between float, double, and long double. __tcc_fpinit is probably redundant on Linux as GLIBC already calls __setfpucw right before calling main. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Generating better i386 code
On Fri, Sep 27, 2013 at 11:21:19AM +1000, Jason Hood wrote: > On 26/09/2013 16:30, Daniel Glöckner wrote: > > On Thu, Sep 26, 2013 at 03:39:45PM +1000, Jason Hood wrote: > >> * 4- & 8-byte structs copy as int/long long (all targets); > > > > did you check if the structure is aligned to a multiple of 4 bytes? > > Otherwise it will crash on ARM. > > No, as I thought structures of these sizes would already be > aligned (as if they were int or long long). Is that not > necessarily the case? No, struct { char x[4]; } has an alignment of 1 byte. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Generating better i386 code
Hi Jason, On Thu, Sep 26, 2013 at 03:39:45PM +1000, Jason Hood wrote: > * 4- & 8-byte structs copy as int/long long (all targets); did you check if the structure is aligned to a multiple of 4 bytes? Otherwise it will crash on ARM. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TCC, king of small exe... hey wait...
On Fri, Sep 20, 2013 at 06:49:05PM +0200, Yann Collet wrote: > - Is it even an objective for TCC to generate small-size exe ? No, Wikipedia refers to the size of the compiler, not to the size of the output. Have you tried GCC's -Os switch? On very small executables padding added by the linker might be significant. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Error: File crti.o/crt1.o Not Found and No Function Renaming
On Tue, Sep 17, 2013 at 07:07:38AM -0500, Cayce Pollard wrote: > tcc: error: file '/project/arm-cc/sysroot/lib//libgcc_s.so.1' not found > tcc: error: undefined symbol '__divsi3' > tcc: error: undefined symbol '__modsi3' > tcc: error: undefined symbol '__aeabi_uidiv' > tcc: error: undefined symbol '__aeabi_uidivmod' > tcc: error: undefined symbol '__aeabi_idiv' > tcc: error: undefined symbol '__aeabi_idivmod' Android links statically against GCC's libgcc.a. See https://android.googlesource.com/platform/bionic.git/+/master/libc/arch-arm/bionic/libgcc_compat.c Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Problem Compiling tinycc For Android: strtold
On Wed, Sep 11, 2013 at 08:26:31PM -0500, Cayce Pollard wrote: > Also, would that work for linking __clear_cache to the Android equivalent > cacheflush? I would prefer directly using the __ARM_NR_cacheflush syscall to make it work on non-Bionic Linux as well. The syscall has been introduced into Linux in 2.3.7pre6. Glibc uses it in libdl after perfoming relocations since 2005 and according to https://github.com/android/platform_bionic/blob/master/libc/arch-arm/syscalls/cacheflush.S it is what Bionic's cacheflush uses under der hood. Unfortunately it is not exposed by Glibc. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Problem Compiling tinycc For Android: strtold
On Wed, Sep 11, 2013 at 03:40:15PM -0500, Cayce Pollard wrote: > ./../tinycc/tccpp.c:1961: error: undefined reference to 'strtold' Just substitute strtod for strtold. It has probably been omitted from Android's libc because long double == double on ARM nowadays (i.e. with EABI or VFP). Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TinyC configuration on WinXP
On Wed, Aug 07, 2013 at 08:37:22PM +0100, James Lyon wrote: > It appears to add CPATH and C_INCLUDE_PATH to the header search path > and LIBRARY_PATH to the linker search. I've not used this mechanism > though. The code for this was added with 0ad857c80e1 after 0.9.26. 0.9.25 didn't use environment variables. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Fastest TCC version
On Fri, Jun 21, 2013 at 05:26:05AM +0530, Sherjil Ozair wrote: > Could anyone direct me to the fastest TCC version that is there right now > for compile-time? > > I downloaded 0.9.26 from http://bellard.org/tcc/. Is this the fastest one? > I expect not, since this is quite an old version. That's a strange question. We don't try to improve the compile-time. I suspect the speed to be almost the same across releases with the later ones being slightly slower due to improved error checking and code optimization. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] libtcc1 again --- on ARMv7
On Sat, May 25, 2013 at 07:08:26PM +0200, Armin Steinhoff wrote: > Thomas Preud'homme wrote: > > Le mercredi 22 mai 2013 15:25:26, Armin Steinhoff a écrit : > >> Do we need the run time environment for ARM ?? > > Yes, for integer division for instance. > > Seems not to be the case. > I'm using only the JIT feature for generation code in memory ... so I > defined in config.h the macro WITHOUT_LIBTCC and all is working for our > real-time soft PLC :) > > libttc1 must only be used if you are going to create application > binaries ... I think in your case there is no need for libtcc1 because your soft PLC has already been linked to libgcc_s.so.1 by GCC, which provides all the symbols that should be found in libtcc1. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] ARM hardfloat prolog
On Thu, May 02, 2013 at 01:02:19PM +0200, Thomas Preud'homme wrote: > Do you know where big-endian is used and by who? There once was a port of > Debian for ARM big endian but it never got much traction so it seems to me > there is not much interest for such a port anyway. No, I don't think I've seen a big endian ARM running Linux or BSD. But I know that there are TMS570 Cortex-R4 hard wired to big endian. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
Hi Rune, On Thu, May 02, 2013 at 10:37:58AM +, u-tcc-u...@aetey.se wrote: > From my perspective I'd like to skip the additional worry about which > programs can be linked to which libraries and "how". if you are a packager, why do you have to worry about that? I mean, if you still have the possibility to chose which library to link to, most of the time the program is already (L)GPL compatible. And if you always use the shared library, there is never a problem with LGPL. > I dislike dynamic linking for technical reasons (too much complexity, > artificial limitations and side effects, many times for no gain). Then, > I dislike licenses which force me to use inferior/inappropriate technical > means. Can you elaborate on that? Aside from some people not understanding how to use SONAMEs (Tegra 2 libjpeg.so binary blob...), I've never had problems with shared libraries. Off the top of my head I remember three cases where shared libs were superior: - Libgcc for ARM once had a bug in the division routine. If all applications had linked to the shared library, it would have been enough to replace just a single file. - Libpng has multiple times been updated because a vulnerability had been found in the code. And guess what, Firefox per default links statically to its own copy of libpng, so you have to replace Firefox as well. - I once had to squeeze ISC DHCP into a little NOR flash but each of the applications was linked statically to several ISC libraries and it appeared like no code was discarded during linking. It all magically fit once I persuaded the build process to create and use shared libraries. > BSD license makes the software easier to package / deliver, which > can make a big difference in certain cases. Btw., how do you at Aetey manage to provide the source code for the (L)GPL software you host? Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] ARM hardfloat prolog
On Wed, May 01, 2013 at 05:02:54PM +0200, Thomas Preud'homme wrote: > Le mercredi 1 mai 2013 16:59:25, Daniel Glöckner a écrit : > > In my 2nd edition ARM ARM this maps to the FSTMS instruction and there > > is a note allowing implementations to keep the values in an internal > > representation and just convert them to IEEE format for storing to > > memory. So I don't think we can use this instruction to store double > > arguments and need one FSTMS/FSTMD for each run of consecutive fpu > > registers of same precision to be stored. Or have read otherwise? > > Nope, I didn't see that line. Please go ahead if you want to fix it, > otherwise > I'll do it later (I'm working right now). I did some more research. ARM ARM 2nd edition (= Issue E) has several paragraphs below figure 2-1 in chapter C2 talking about that no assumptions can be made as to how single-precision registers overlap double-precision registers and that the value of double-precision registers after their corresponding single- precision registers have been loaded with a value becomes UNPREDICTABLE. Issue I, which can be downloaded after registering with ARM, replaces that half page of text with "The mapping between a double-precision register and its pair of single-precision registers is as follows: - S<2n> lies in the least significant half of D - S<2n+1> lies in the most significant half of D." So we are safe with the current implementation, at least on little-endian ARM. On big-endian ARM the halves will have the wrong order if we don't use FSTMD, but there is a lot more that needs to be done until we support big-endian ARM. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
On Tue, Apr 30, 2013 at 07:12:50PM +0200, Daniel Glöckner wrote: > On Tue, Apr 30, 2013 at 07:07:34PM +0200, Thomas Preud'homme wrote: > > Mmmmh. Overall I'm more a (A|L)GPL guy but I choose different license for > > different project. For tcc I thought it could make sense since we have only > > libtcc has static lib and many people seem to build stuff around it. > > And if I volunteer to extend the Makefile for a shared libtcc? We already have rules for libtcc.so.1.0 and libtcc.dll in our Makefile. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Recent changes segfault on Linux ARM
Hi Christian, On Wed, May 01, 2013 at 04:44:09PM +0200, Christian Jullien wrote: > ARM hardfloat: fix struct return with float/double args > > Fixes the case where the structure is not returned in registers. > > I thought it was related to ret_2float_test > > At least on Rpi I still have: > > ret_2float_test... Segmentation fault well, it should still crash if you compile abitest.c with GCC, as the first of the two issues is not resolved. With TinyCC it should work though, judging from visual inspection of the disassembly. Which hardfp environment do you use for the Rpi? Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] ARM hardfloat prolog
Hi Thomas, I saw that you used the following line to store the floating point arguments that have been passed in fpu register: o(0xED2D0A00|nf); /* save s0-s15 on stack if needed */ In my 2nd edition ARM ARM this maps to the FSTMS instruction and there is a note allowing implementations to keep the values in an internal representation and just convert them to IEEE format for storing to memory. So I don't think we can use this instruction to store double arguments and need one FSTMS/FSTMD for each run of consecutive fpu registers of same precision to be stored. Or have read otherwise? Best regards, Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Recent changes segfault on Linux ARM
On Fri, Apr 26, 2013 at 10:58:39PM +0200, Daniel Glöckner wrote: > There are two things broken in the code generated by TCC: > First of all TCC thinks it has to return the structure in > memory pointed to by r0 and second it gets confused about where > it stored r0 and instead reads the first float from the stack > and interpretes that as a pointer. The latter should be fixed by the one-liner I just committed. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
Hi, On Tue, Apr 30, 2013 at 09:14:58PM +0200, Marc Andre Tanner wrote: > The fear of proprietary forks seems > unfounded because there is already a mature BSD licensed C compiler > (clang) available for people to base their work on. Let's see.. $ size /opt/llvm/bin/clang textdata bss dec hex filename 389997781193992 54640 40248410266245a /opt/llvm/bin/clang I think TinyCC might be preferred by some people who just need a small scripting engine. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
On Tue, Apr 30, 2013 at 07:07:34PM +0200, Thomas Preud'homme wrote: > Mmmmh. Overall I'm more a (A|L)GPL guy but I choose different license for > different project. For tcc I thought it could make sense since we have only > libtcc has static lib and many people seem to build stuff around it. And if I volunteer to extend the Makefile for a shared libtcc? Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
On Tue, Apr 30, 2013 at 05:43:03PM +0200, Thomas Preud'homme wrote: > As I already said privately, I'm fine with BSD-2-clause. Does that mean you prefer it over the LGPL? What about you, grischka? Which one do you prefer? Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Do we want a BSD license for tinycc?
On Tue, Apr 30, 2013 at 03:40:43PM +0200, grischka wrote: > So the questions is: Do you people want, is it possible, what > would it take - to change our tinycc code's license from LGPL > to a BSD-like one (such as below). > > Please discuss. I don't see anything good coming from a change from LGPL to BSD. It just encourages people to create private forks for binary-only releases. And I have yet to hear anyone complain on this list that they can't use TinyCC in their product because they can't link dynamically to the library. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Recent changes segfault on Linux ARM
On Fri, Apr 26, 2013 at 10:58:39PM +0200, Daniel Glöckner wrote: > And I am not happy that is_fconst() apparently does not work. Scratch that. is_fconst() is for FPA an the VMOV (imm) instruction I saw in the output of GCC is VFPv3. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Recent changes segfault on Linux ARM
On Fri, Apr 26, 2013 at 08:27:25PM +0100, James Lyon wrote: > I think that ARM should use a hidden pointer to return > the data in ret_2float_test, but reading the ARM EABI spec a > structure with 2 floats in might count as a "64-bit containerized > vector" and thus would be returned in r0 and r1. In that case I > think the thing to do is modify gfunc_sret to detect this. GCC with hard float ABI returns the structure in s0 and s1. There are two things broken in the code generated by TCC: First of all TCC thinks it has to return the structure in memory pointed to by r0 and second it gets confused about where it stored r0 and instead reads the first float from the stack and interpretes that as a pointer. And I am not happy that is_fconst() apparently does not work. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] RE :Re: ARM code generator / ARM tiny C compiler
On Thu, Apr 25, 2013 at 04:05:24PM +0200, Christian JULLIEN wrote: > Wouah! > Do you mean you're implementing eabi_ functions for ARM (such as div and > mod ?) > Total respect!! I once had an incomplete libtcc1 on my homepage, where I used a division function from GMP. It could not be compiled with TinyCC because of the missing ARM assembler. At one point I stopped trying to reinvent the wheel and started to point everyone to libgcc. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] ARM code generator / ARM tiny C compiler
On Thu, Apr 25, 2013 at 01:11:42PM +0200, Armin Steinhoff wrote: > libtcc1.c doesn't compile for ARMv7 :) libtcc1.c doesn't contain the functions needed for ARM. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] ARM code generator / ARM tiny C compiler
On Thu, Apr 25, 2013 at 09:27:46AM +0200, ggasnie...@free.fr wrote: > Could supported more ARM architecture and instructions set be of interest ? Thumb and EABI soft float support would be nice. The other instructions added with ARMv5/6/7 are probably useless given the little amount of optimization done by TinyCC. The architectures < v4 belong into museums and the 64 bit ARMv8 architecture has not yet reached production AFAIK. > I'd like to work on it on my free time (long-term roadmap). Just go ahead in whatever direction you like. The possibility of colliding with someone else working on the same part of TinyCC is close to zero. And if you do, you just have to be faster at committing to the mob branch of the git repository :) Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] ARM code generator / ARM tiny C compiler
On Wed, Apr 24, 2013 at 10:15:29PM +0200, ggasnie...@free.fr wrote: > So where could I find the supported ARM architecture The generated code should be compatible with ARMv4. Floating point hardware or emulator (either FPA or VFP) is a must. > and what is the roadmap for it ? There is no central roadmap. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] ARM code generator / ARM tiny C compiler
On Wed, Apr 24, 2013 at 06:00:17PM +0200, ggasnie...@free.fr wrote: > Are there people working on the feature ? > For this long-term feature, what are the main aspects of TCC to > understand before going forward ? What do you miss in the current TCC ARM code generator? Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] libtcc1 supported for ARMv7 ?
Hi, On Wed, Apr 24, 2013 at 12:25:07PM +0200, Armin Steinhoff wrote: > I'm trying to use the JIT capabilitiy of TCC for an ARMv7 environment > (Beaglebone / QNX6 ..) but the libtcc1 can't be recompiled for ARM CPUs. libtcc1 doesn't compile for ARM. ARM users shoud use libgcc.a/libgcc_s.so.1. Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] global variables in tcc
Hi, On Mon, Apr 01, 2013 at 04:55:18PM +0200, Lluís Batlle i Rossell wrote: > > GCC and Clang allow these to be merged together at link-time, which > > means users who make mistakes such as missing `extern' in header files > > still get the multiple definitions merged. > > > > tcc is stricter and perhaps more conformant in disallowing this. > > I think that the C standard requires the gcc and clang behaviour, 'extern' > never being a required word. > > No? I just took a look inside the N1570 C11 draft. Chapter 6.9 paragraph 5 says: "If an identifier declared with external linkage is used in an expression ([...]), somewhere in the entire program there shall be exactly one external definition for the identifier; otherwise, there shall be no more than one." Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Compiling preprocessed files with tinycc?
On Wed, Mar 20, 2013 at 01:01:10PM -0700, Austin English wrote: > manually correcting that, I'm able to preprocess the problematic file down to: > austin@debian-home:~/src/wine-tcc/dlls/d3d8/tests$ cat stateblock.i.tcc.c > typedef struct _D3DVECTOR > { > float x; > float y; > float z; > } D3DMATRIX; You are aware that D3DMATRIX is supposed to consist of 16 floats? Daniel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel