[Tinycc-devel] Re : Questions about the future of TinyCC

[david . koch]

Hi César,

you may want to consider PellesC which support OpenMP to some extend :

http://www.smorgasbordet.com/pellesc/sourcecode.htm

PellesC is a fork of LCC with many improvements :

http://www.smorgasbordet.com/pellesc/

Regards.


- Mail d'origine -
De: Ces VLC 
À: tinycc-devel@nongnu.org
Envoyé: Mon, 01 Apr 2024 12:43:54 +0200 (CEST)
Objet: [Tinycc-devel] Questions about the future of TinyCC

Hi!

I develop in C for Linux (Intel), Mac (Intel and soon also Apple Silicon),
and for Windows (Intel). With the years I'm becoming more and more
reluctant to GCC and LLVM, which are the two compilers I use, because they
have grown into C++ monsters and building them is a huge adventure that
takes more and more effort -days or even weeks in some cases- in every new
version they release (I won't go into the details, but if you are used to
build and test new versions of GCC and LLVM for several targets, you know
what I'm talking about).

Basically, what I need is just a C compiler. Written in C. A good C
compiler. With a not too complex code tree and reasonably easy to port to
new targets in the future. That's it.

It seems the old "portable C compiler" is either gone or abandoned (the
website is down). Another historical one, Amsterdam Toolkit (ATK) is not
maintained for new targets such as Apple Silicon. The same can be said for
LCC and OpenWatcom... and then, looking at the list of C compilers in
Wikipedia, it seems like I already mentioned all the available open source
and multiplatform C compilers but TinyCC.

TinyCC looks very appealing to me, but, before I embark on it, are there
any important warnings I should be aware of? Does anybody use it on MacOS
on a daily basis? With Apple Silicon? Does hardware floating point work
fine in float and double precision on Intel x86, x86_64, and on Apple
Silicon?

Also: are there plans to support OpenMP, or do you know of any tool that I
can use for parsing a C source with OpenMP pragmas and generating a
pthreads version of the parallelized code that I can then build with
TinyCC? The thing is that all recent CPUs are multicore, and you are sort
of wasting them if you don't parallelize costly loops... and OpenMP lets
you do this in a very convenient way. Maybe a complete OpenMP
implementation would increase the complexity of TinyCC (I'm not really
sure, I don't know the details), that's why I'm asking for an alternative
that I could use, a sort of "OpenMP preprocessor" before sending the source
to TinyCC.

Another thing that could be important to me is the license. The current
LGPL might be fine, but I'd like to have at least a "static link exception"
so that, in the case that I need to statically link TinyCC with any of my
programs in the future, the license is not viral into my program. I've seen
that there's an effort in relicensing TinyCC into a MIT-like license, how
is it going? Will it succeed?

Kind regards, and thanks a lot,

César


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

[Tinycc-devel] Re : Re: TinyCC on Windows & some suggestions

[david . koch]

Hi Robert,

nice job, but why not using https://github.com/anael-seghezzi/CToy ?

It already have everything you need, plus hot-reload capability.

Regards.

- Mail d'origine -
De: Robert Schlicht 
À: tinycc-devel@nongnu.org
Envoyé: Mon, 11 Mar 2024 20:38:52 +0100 (CET)
Objet: Re: [Tinycc-devel] TinyCC on Windows & some suggestions

Yes, it is. But it’s really primitive, basically just a text editor that has 
the compiler integrated, and calling it an IDE may be an exaggeration. It’s the 
thing that is intended to make writing a “Hello, World!” program (and slightly 
more interesting stuff) as painless as possible for beginners.

Robert


Jake Anderson (2024-03-11 15:10):
> Is the IDE open source? An IDE that is packaged separately and uses the TCC
> compiler could be useful.
> 
> On Sun, Mar 10, 2024 at 1:01 PM Robert Schlicht  wrote:
> 
> > At our university we offer a course where we program simple spatial
> > simulations in various programming languages, one of them being C, for
> > illustrating close-to-the-machine programming concepts. We here need a C
> > implementation that is small (since it’s accessed over a network), works
> > out of the box on Windows computers (since our students are beginners) and
> > runs fast (so compiler errors are available instantaneously). We do not
> > need advanced developer tools, and code running three times slower is
> > acceptable because that is still faster than scripting languages.
> >
> > TCC is obviously a good option here, and for our course starting in April
> > of this year, I put together a package https://rschlicht.eu/tc-ide.zip
> > that includes a minimalist IDE running TCC and a very basic form of a C
> > standard library, all contained in a standalone executable tc-ide.exe. The
> > library is just headers that directly access the Windows API (no runtime
> > needed) and should satisfy the requirements of a conforming freestanding
> > implementation, while also including common memory, file, math and the
> > printf family of functions. (If anyone finds this useful, I’ll gladly
> > contribute it to the TCC project.)
> >
> > The executable is compiled by itself, although this currently requires a
> > few hacks and workarounds to get it working as desired. I list these here
> > as suggestions for improving TCC:
> >
> > (1) For using TCC as a library, it would be nice if it did a more thorough
> > cleanup:
> > – In a few places exit() is called in case of failure, but terminating the
> > program is not very user-friendly; cleanly propagating failure or even some
> > longjmp hacks might provide a better solution. [tc-ide does the latter,
> > while patching function calls to keep track of memory and open files.]
> > – Another problem I encountered is that TCC does not always properly
> > restore the state of the global variables; compiling the following code
> > fragment the first time produces an error message (as it should), but the
> > second time it causes an exception (which I assume is a bug):
> > void nothing(void) {for ( ; ; ) break;}  void garbage(void) {switch
> > [The workaround in tc-ide is ugly but straightforward: Make a copy of the
> > memory block containing all global variables, and restore this block after
> > TCC returns.]
> >
> > (2) I really appreciate that TCC can directly link to functions in Windows
> > DLLs with no auxiliary .lib file and that it even supports directives like
> > #pragma comment(lib,"kernel32"). The current implementation of the DLL
> > lookup with a huge number of lseek & read calls (via read_mem() in tccpe.c)
> > may be inefficient on some file systems. [tc-ide avoids this issue by
> > creating file mappings in memory and redirecting lseek and read to those
> > memory buffers, which it has to deal with anyway to access the embedded
> > headers.]
> >
> > (3) The C23 preprocessor directive #embed would be of help for embedding
> > headers and other files as byte arrays in the program. [tc-ide currently
> > does this by providing a non-standard feature with a custom notation like
> > #include "stdlib.h#".]
> >
> > (4) TCC uses fixed buffer sizes for file paths in certain places. For
> > example, libtcc.c has 260(=MAX_PATH) in config_tccdir_w32() and
> > _fullpath(), 1000 in tcc_add_systemdir() and 1024 in
> > tcc_add_library_internal(), while tccelf.c has 1024 in getcwd(). Windows
> > has been supporting long file paths for quite a while now, so it might be
> > better to allocate those buffers dynamically:
> > https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation
> >
> > (5) Some rarely used C library functions could perhaps be replaced to make
> > the code less dependent on such features. Examples are the single use of
> > alloca() in libtcc.c to set up a buffer and the use of scanf() in tccpp.c
> > to convert the TCC version string into a number. [tc-ide here provides
> > stubs.]
> >
> > (6) It would be useful to allow the user to set the entry point symbol
> > (either the 

[Tinycc-devel] Re : Minimizing libtcc memory use

[david . koch]

Hi,

isn't there a garbage collecting done at the end to remove all the unused stuff 
to produce a binary that contains only the necessary parts ?

Regards.

- Mail d'origine -
De: Eric Raible 
À: tinycc-devel@nongnu.org
Envoyé: Thu, 29 Feb 2024 08:43:17 +0100 (CET)
Objet: [Tinycc-devel] Minimizing libtcc memory use

In my use case I typically give libtcc code a few hundred lines of code:

1) some standard includes:
#include 
#include 
#include 

2) ~100 lines of #defines
3) ~50 lines of structs and typedefs
4) ~70 lines of function and data declarations (externs)
5) ~100 lines of actual code and data
6) The TCCState has ~50 symbols added with tcc_add_symbol().

All that is well and good, and it works perfectly.  The problem is that the
above uses roughly 30K bytes of memory.  But the actual code and data
looks to be between a few hundred and a few thousand bytes.  So a
50x reduction looks feasible.

I can envision a new API that would flush all unnecessary info.
For instance:  int tcc_finalize(TCCState *);
After such a call the only valid operation on the TCCState would be
tcc_delete().

Two questions, if I may:
1) Is something like this of interest to anyone else?
2) Can anyone estimate how difficult this is?  I might be able to sponsor
development of such a feature if that would help.

Thanks - Eric


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

[Tinycc-devel] Re : Re: Re : Re: Where do I get pthread.h?

[david . koch]

Not trolling, I love C, and even more so assembler.

But let's face it, "C" as a language is spawned into many incarnations.

All barely compatible with each other, unless you stick to C89. If so.

About libraries, pthread is not even present on Windows, unless Cygwin or so.

To progress you have to learn from your flaws and failures.

C23 has become a mixture of various other languages out there to the point it 
becomes abhorrent.

https://en.wikipedia.org/wiki/C23_(C_standard_revision)

Only to stay "relevant" yet TCC won't never be able to reach full conformance.

TCC is a great project, but the real priority is bug fixing for already 
established standards.

That the TCC packaging could be misleading is indeed a problem for newcomers.

Hence I made a TCC "distro" more featured (include files) :

https://github.com/Kochise/tinycc_win32/tree/master/win32

Yet still no "pthread.h" hence this fails :

https://github.com/Kochise/tinycc_win32/blob/master/tests/tests2/106_pthread.c

That's be great to provide a complete self sustaining portable package that 
pass all its own tests.

Anyway, I use TCC to compile an old project before Pioneer existed :

https://github.com/Kochise/GLFrontier-win32/blob/main/src/Makefile-tcc.bat

https://github.com/pioneerspacesim/pioneer -> 
https://wiki.pioneerspacesim.net/wiki/FAQ#What.27s_the_history_of_Pioneer

https://pioneerspacesim.itch.io/pioneer / 
https://pioneerspacesim.net/page/download/

So, see, I still use TCC, but try to work around it's limitations.

So not "trolling" that much.

People should deliver a better experience of their beloved language.

Regards.




- Mail d'origine -
De: gz8...@0w.se
À: tinycc-devel@nongnu.org
Envoyé: Wed, 07 Feb 2024 18:30:43 +0100 (CET)
Objet: Re: [Tinycc-devel]  Re : Re: Where do I get pthread.h?

Regarding a reply to my message:

On Wed, Feb 07, 2024 at 04:04:30PM +0100, david.k...@libertysurf.fr wrote:
> Indeed, I'd say focus on more up to date and elaborate programming languages.
> C, while nice as a "portable assembler" is still full of quirks and tricks.
> Which show how unstable and unprofessional it is 50 years after its creation.
> Many "extensions" and as you state, "unfortunately" packaged by many vendors.

Let us make some observations.

1. This is a list dedicated to a C compiler. Insulting the language of our
interest, with the knowledge of our (mostly quite well informed) choices,
is not a friendly behavior.

2. Historical packaging practices and their unfortunate pedagogical
consequences are not a property of the language. I am quoted in a very
misleading way.

3. What does it actually mean, an "unprofessional" programming language?
Whose professionalism is meant? An insult against its users? Something else?

An incoherent inflammatory message indicates ... trolling.

Not worth to react to.

Regards,
/tccm

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


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

[Tinycc-devel] Re : Re: Where do I get pthread.h?

[david . koch]

Indeed, I'd say focus on more up to date and elaborate programming languages.

C, while nice as a "portable assembler" is still full of quirks and tricks.

Which show how unstable and unprofessional it is 50 years after its creation.

Many "extensions" and as you state, "unfortunately" packaged by many vendors.

Good luck.

Regards.


- Mail d'origine -
De: gz8...@0w.se
À: tinycc-devel@nongnu.org
Envoyé: Wed, 07 Feb 2024 15:39:33 +0100 (CET)
Objet: Re: [Tinycc-devel] Where do I get pthread.h?

On Tue, Feb 06, 2024 at 08:25:17PM -0800, Videogamer555 wrote:
> I was trying to compile a program that requires pthread.h (which is a
> header file that comes with GCC by default, and I thought that TCC was
> supposed to be GCC compatible) but TCC is missing pthread.h unfortunately.

This header belongs to the C library, not to a compiler.

If your system lacks it, then it is the libc which is incomplete, not tinycc.

(the distinction between which headers are part of what is far from
easy to trace, often obscured by packaging practices, this is unfortunate)

Regards,
/tccm

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


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

[Tinycc-devel] Re : Lock-free tcc

[david . koch]

Thank you.

Regards.

- Mail d'origine -
De: Richard Allen 
À: tinycc-devel@nongnu.org
Envoyé: Tue, 12 Sep 2023 18:45:10 +0200 (CEST)
Objet: [Tinycc-devel] Lock-free tcc

Hello,

It's my first time posting to this list.

A bit ago I started playing with the idea of a multi-threaded compiler,
and put together a prototype using libtcc. I ran into the code-gen
mutex as a bottleneck.

It's based on an older commit, but I was able to refactor all global variables
into TCCState and remove the mutexes to get better scaling.

I'm not sure if this work would be useful to anyone else,
but thought I would share with this list.

https://github.com/rsaxvc/tinycc-multithreaded

-Richard

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


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

[Tinycc-devel] Re : Re: Re : Re: Re : Re: win32: -Wl,-nostdlib: undefined symbol 'memset'

[david . koch]

Hi,

when using those "bare metal" options, you are not free to presume what the 
compiler will do.

While I understand a simple assignation would be converted to the MOV 
equivalent, no so for structs.

Not all compilers behave the same though, hence have a look on their respective 
documentation :

https://stackoverflow.com/questions/75257104/is-it-considered-normal-that-nostdlib-does-not-prevent-gcc-clang-to-generate-ca

https://stackoverflow.com/questions/59612257/difference-between-ffreestanding-and-nostdlib-when-compiling-with-gcc

http://cs107e.github.io/guides/gcc/

https://renenyffenegger.ch/notes/development/languages/C-C-plus-plus/GCC/options/no/compare-nostartfiles-nodefaultlibs-nolibc-nostdlib

Regards.


- Mail d'origine -
De: avih via Tinycc-devel 
À: tinycc-devel@nongnu.org
Cc: avih 
Envoyé: Tue, 12 Sep 2023 13:08:39 +0200 (CEST)
Objet: Re: [Tinycc-devel] Re : Re: Re : Re: win32: -Wl,-nostdlib: undefined 
symbol 'memset'

 On Tuesday, September 12, 2023 at 12:44:45 PM GMT+3, grischka  
wrote:

On 12.09.2023 11:01, avih via Tinycc-devel wrote:
>> Tcc does not guarantee to compile pure C code into pure machine code,
>> and any pure-C implementation which the user provides might end up
>> depending on those functions involuntarily. The user has no control..

> How do you define "pure C code"?

What I had in mind in this case was a C function which does not
use asm and does not call other functions, like this:

void *memset(void *str, int c, size_t n) {
 unsigned char *s = str;
 while (n--)
 *s++ = c;
 return str;
}

> And were did you get that that a compiler should be able to produce
> runnable binaries from such "pure C" without calling into any library
> functions?

I did not say that. I was trying to explain the scope of the issue.

> Also, what is "pure machine code"? With neither input nor output it
> couldn't do anything but waste instruction cycles.

A function implemented in machine code, where the input is the
arguments in whatever calling convention the implementation uses,
and the output is the return value and whatever memory side effects.

I was hoping that compiling a C function which does not call other
functions would result in machine code which does not call functions,
except maybe existing internal compiler functions.

In the example above it probably does not call external functions.
But the user can't tell when it does and when it doesn't, which makes
-nostdlib very problematic from a practical point of view.

At this stage it's clear that external functions are expected, so the
next step, if we want to have a usable -nostdlib, is to define the spec
which a user has to follow in order to use it.

My initial suggestion was to document the mem* and whatever other
implementations which are required, possibly with a suggestion to link
-ltcc1.

But because the user can't tell if their "pure C" mem* implementations
end up recursive or not, my second semi-suggestion was that maybe
libtcc1 could provide such implementations which it can guarantee to
not depend on external functions, and which the user may utilize if
they don't intend to implement these functions in asm themselves.

Even if these are terrible suggestions, the question remains:

What does the user need to do in order to use -nostdlib?

And maybe also: what is -stdlib good for?

- avih
  

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

[Tinycc-devel] Re : Re: Re : Re: win32: -Wl,-nostdlib: undefined symbol 'memset'

[david . koch]

Thank, that's valuable information in one place.

Regards.

- Mail d'origine -
De: grischka 
À: tinycc-devel@nongnu.org
Envoyé: Mon, 11 Sep 2023 21:31:24 +0200 (CEST)
Objet: Re: [Tinycc-devel] Re : Re: win32: -Wl,-nostdlib: undefined symbol 
'memset'

On 11.09.2023 14:41, avih via Tinycc-devel wrote:
> But in the case of tcc, it's not documented, and seems to go
> quite a bit further than what gcc requires

libgcc.a from mingw-gcc-6.3.0 is 6218 kB, all full with according
to your standards "undocumented" stuff that however gcc surely
will require under certain circumstances and will miss when
-nostdlib given.  List follows:

_chkstk.o___chkstk
_chkstk.o__alloca
_chkstk_ms.o___chkstk_ms
_muldi3.o___muldi3
_negdi2.o___negdi2
_lshrdi3.o___lshrdi3
_ashldi3.o___ashldi3
_ashrdi3.o___ashrdi3
_cmpdi2.o___cmpdi2
_ucmpdi2.o___ucmpdi2
_clear_cache.o___clear_cache
_trampoline.o_getpagesize
_trampoline.o_mprotect
__main.o___do_global_dtors
__main.o___do_global_ctors
__main.o___main
_absvsi2.o___absvsi2
_absvdi2.o___absvdi2
_addvsi3.o___addvsi3
_addvdi3.o___addvdi3
_subvsi3.o___subvsi3
_subvdi3.o___subvdi3
_mulvsi3.o___mulvsi3
_mulvdi3.o___mulvdi3
_negvsi2.o___negvsi2
_negvdi2.o___negvdi2
_ctors.o___DTOR_LIST__
_ctors.o___CTOR_LIST__
_ffssi2.o___ffssi2
_ffsdi2.o___ffsdi2
_clz.o___clz_tab
_clzsi2.o___clzsi2
_clzdi2.o___clzdi2
_ctzsi2.o___ctzsi2
_ctzdi2.o___ctzdi2
_popcount_tab.o___popcount_tab
_popcountsi2.o___popcountsi2
_popcountdi2.o___popcountdi2
_paritysi2.o___paritysi2
_paritydi2.o___paritydi2
_powisf2.o___powisf2
_powidf2.o___powidf2
_powixf2.o___powixf2
_powitf2.o___powitf2
_mulsc3.o___mulsc3
_muldc3.o___muldc3
_mulxc3.o___mulxc3
_multc3.o___multc3
_divsc3.o___divsc3
_divdc3.o___divdc3
_divxc3.o___divxc3
_divtc3.o___divtc3
_bswapsi2.o___bswapsi2
_bswapdi2.o___bswapdi2
_clrsbsi2.o___clrsbsi2
_clrsbdi2.o___clrsbdi2
_fixunssfsi.o___fixunssfsi
_fixunsdfsi.o___fixunsdfsi
_fixunsxfsi.o___fixunsxfsi
_fixsfdi.o___fixsfdi
_fixdfdi.o___fixdfdi
_fixxfdi.o___fixxfdi
_fixunssfdi.o___fixunssfdi
_fixunsdfdi.o___fixunsdfdi
_fixunsxfdi.o___fixunsxfdi
_floatdisf.o___floatdisf
_floatdidf.o___floatdidf
_floatdixf.o___floatdixf
_floatundisf.o___floatundisf
_floatundidf.o___floatundidf
_floatundixf.o___floatundixf
_eprintf.o___eprintf
__gcc_bcmp.o___gcc_bcmp
_divdi3.o___divdi3
_moddi3.o___moddi3
_udivdi3.o___udivdi3
_umoddi3.o___umoddi3
_udiv_w_sdiv.o___udiv_w_sdiv
_udivmoddi4.o___udivmoddi4
bid_decimal_globals.o___dfp_set_round
bid_decimal_globals.o___dfp_get_round
bid_decimal_globals.o___dfp_clear_except
bid_decimal_globals.o___dfp_test_except
bid_decimal_globals.o___dfp_raise_except
bid_decimal_globals.o___bid_IDEC_glbround
bid_decimal_globals.o___bid_IDEC_glbflags
bid_decimal_data.o___bid_power10_index_binexp_128
bid_decimal_data.o___bid_reciprocals10_64
bid_decimal_data.o___bid_short_recip_scale
bid_decimal_data.o___bid_power10_index_binexp
bid_decimal_data.o___bid_estimate_bin_expon
bid_decimal_data.o___bid_power10_table_128
bid_decimal_data.o___bid_estimate_decimal_digits
bid_decimal_data.o___bid_recip_scale
bid_decimal_data.o___bid_reciprocals10_128
bid_decimal_data.o___bid_round_const_table_128
bid_decimal_data.o___bid_round_const_table
bid_binarydecimal.o___bid32_to_binary32
bid_binarydecimal.o___bid64_to_binary32
bid_binarydecimal.o___bid128_to_binary32
bid_binarydecimal.o___bid32_to_binary64
bid_binarydecimal.o___bid64_to_binary64
bid_binarydecimal.o___bid128_to_binary64
bid_binarydecimal.o___bid32_to_binary80
bid_binarydecimal.o___bid64_to_binary80
bid_binarydecimal.o___bid128_to_binary80
bid_binarydecimal.o___bid32_to_binary128
bid_binarydecimal.o___bid64_to_binary128
bid_binarydecimal.o___bid128_to_binary128
bid_binarydecimal.o___binary32_to_bid32
bid_binarydecimal.o___binary64_to_bid32
bid_binarydecimal.o___binary80_to_bid32
bid_binarydecimal.o___binary128_to_bid32
bid_binarydecimal.o___binary32_to_bid64
bid_binarydecimal.o___binary64_to_bid64
bid_binarydecimal.o___binary80_to_bid64
bid_binarydecimal.o___binary128_to_bid64
bid_binarydecimal.o___binary32_to_bid128
bid_binarydecimal.o___binary64_to_bid128
bid_binarydecimal.o___binary80_to_bid128
bid_binarydecimal.o___binary128_to_bid128
bid_convert_data.o___bid_factors
bid_convert_data.o___bid_packed_1_zeros
bid_convert_data.o___bid_convert_table
_isinfd32.o_isinfd32
_isinfd64.o_isinfd64
_isinfd128.o_isinfd128
bid64_noncomp.o___bid64_isSigned
bid64_noncomp.o___bid64_isNormal
bid64_noncomp.o___bid64_isSubnormal
bid64_noncomp.o___bid64_isFinite

[Tinycc-devel] Re : Re : Re: win32: -Wl,-nostdlib: undefined symbol 'memset'

[david . koch]

Try this :

https://github.com/JHRobotics/nocrt

Regards.

- Mail d'origine -
De: david koch 
À: tinycc-devel@nongnu.org
Cc: avih 
Envoyé: Sat, 09 Sep 2023 20:41:15 +0200 (CEST)
Objet: Re : Re: [Tinycc-devel] win32: -Wl,-nostdlib: undefined symbol 'memset'

Hi,

I think you got it all wrong, please reread how a compiler work.

The stdlib is just a glue/wrapper to the underlying operating system, here 
Windows or Linux.

But what about an embedded/osless environment ? You provide your own stdlib in 
that case.

Hence TCC's purpose is not to provide its own 'stdlib' if you specifically 
request not to.

'memset' is one of the many functions you have to stub with your own 
implementation.

Good luck with that.

Regards.


- Mail d'origine -
De: avih via Tinycc-devel 
À: tinycc-devel@nongnu.org
Cc: avih 
Envoyé: Sat, 09 Sep 2023 19:54:08 +0200 (CEST)
Objet: Re: [Tinycc-devel] win32: -Wl,-nostdlib: undefined symbol 'memset'

 I don't think that's a valid argument.

This is plain C code which on its own doesn't require the standard library,
so I don't think the user should provide an alternative standard library
implementation just so that the startup code which tcc uses can be linked.

Today it seems that only `memset` is missing, but what if tomorrow the startup
code also wants some other stdlib functions?

I don't think the user should be responsible for this and/or track the 
requirements.

Instead, in cases where stdlib is not linked, I think tcc should use its own
implementations as needed. In this case a trivial memset is a two LOC function.

- avih
 On Saturday, September 9, 2023 at 08:02:25 PM GMT+3,  
wrote:  
 
 you tell tcc to ignore the std c library during linking, so you have to
provide an implementation yourself.
tcc uses memset to init  'buf'


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


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

[Tinycc-devel] Re : where are the functions?

[david . koch]

Hi,

check https://github.com/Kochise/tinycc_win32 I've added more win32 header 
files.

It's defined in winuser.h though.

Regards.


- Mail d'origine -
De: Dieter Dewald 
À: tinycc-devel@nongnu.org
Envoyé: Sun, 10 Sep 2023 04:55:48 +0200 (CEST)
Objet: [Tinycc-devel] where are the functions?

10.09.2023
i used tcc-0.9.27-win64-bin.zip,
i written #include  else no include,
but i got this error-message:

tcc: error: undefined symbol 'DefWindowProcA'
tcc: error: undefined symbol 'LoadIconA'
tcc: error: undefined symbol 'RegisterClassA'
tcc: error: undefined symbol 'CreateWindowExA'
tcc: error: undefined symbol 'ShowWindow'
tcc: error: undefined symbol 'UpdateWindow'
tcc: error: undefined symbol 'DestroyWindow'
tcc: error: undefined symbol 'RegisterClassExA'
tcc: error: undefined symbol 'MoveWindow'
tcc: error: undefined symbol 'GetDC'
tcc: error: undefined symbol 'BeginPaint'
tcc: error: undefined symbol 'EndPaint'
tcc: error: undefined symbol 'ReleaseDC'
tcc: error: undefined symbol 'SetTextColor'
tcc: error: undefined symbol 'SetBkColor'
tcc: error: undefined symbol 'SetBKMode'
tcc: error: undefined symbol 'CreateFontA'
tcc: error: undefined symbol 'SelectObject'
tcc: error: undefined symbol 'DeleteObject'
tcc: error: undefined symbol 'SetPixel'
tcc: error: undefined symbol 'CreateSolidBrush'
tcc: error: undefined symbol 'FillRect'
tcc: error: undefined symbol 'TextOutA'
tcc: error: undefined symbol 'PeekMessageA'
tcc: error: undefined symbol 'GetAsyncKeyState'
tcc: error: undefined symbol 'GetSystemMetrics'
tcc: error: undefined symbol 'main'

i have no main, and i written the functions without A


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

[Tinycc-devel] Re : Re: win32: -Wl,-nostdlib: undefined symbol 'memset'

[david . koch]

Hi,

I think you got it all wrong, please reread how a compiler work.

The stdlib is just a glue/wrapper to the underlying operating system, here 
Windows or Linux.

But what about an embedded/osless environment ? You provide your own stdlib in 
that case.

Hence TCC's purpose is not to provide its own 'stdlib' if you specifically 
request not to.

'memset' is one of the many functions you have to stub with your own 
implementation.

Good luck with that.

Regards.


- Mail d'origine -
De: avih via Tinycc-devel 
À: tinycc-devel@nongnu.org
Cc: avih 
Envoyé: Sat, 09 Sep 2023 19:54:08 +0200 (CEST)
Objet: Re: [Tinycc-devel] win32: -Wl,-nostdlib: undefined symbol 'memset'

 I don't think that's a valid argument.

This is plain C code which on its own doesn't require the standard library,
so I don't think the user should provide an alternative standard library
implementation just so that the startup code which tcc uses can be linked.

Today it seems that only `memset` is missing, but what if tomorrow the startup
code also wants some other stdlib functions?

I don't think the user should be responsible for this and/or track the 
requirements.

Instead, in cases where stdlib is not linked, I think tcc should use its own
implementations as needed. In this case a trivial memset is a two LOC function.

- avih
 On Saturday, September 9, 2023 at 08:02:25 PM GMT+3,  
wrote:  
 
 you tell tcc to ignore the std c library during linking, so you have to
provide an implementation yourself.
tcc uses memset to init  'buf'


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

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

[Tinycc-devel] Re : Re: Relative paths of include files are not normalised, which can break #pragma once

[david . koch]

> I created a new patch where I removed the stat call.
> I now calculate the full path name on linux and windows.
> This means that soft/hard links do not work any more.
> There is still a small slowdown because we create/compare the full path 
> name now.
> But it is about 0.1% on my 64 bits x86_64 machine. Hard to measure correct.

What is the incentive about this ?

Feature and usefulness vs speed and benchmark prowess ?

Who is going to arbitrate what tcc is supposed to do exactly ?


Regards.


- Mail d'origine -
De: Herman ten Brugge via Tinycc-devel 
À: tinycc-devel@nongnu.org
Cc: Herman ten Brugge 
Envoyé: Fri, 07 Jul 2023 20:09:03 +0200 (CEST)
Objet: Re: [Tinycc-devel] Relative paths of include files are not normalised, 
which can break #pragma once

On 7/7/23 08:59, grischka wrote:
> On 07.07.2023 07:45, draco wrote:
>> Hermann,
>>
>> I tested your patch a bit, seems to work as expected and brings tcc
>> win32 back to it's normal speed.
>
> It might be too slow on linux too ...
>
> Basically the "#ifndef cache" is meant to make it faster,
> while the #pragma once also needs to detect path aliases.
>
> That is two different goals in the first place.
>
> Another goal in tinycc is simple code.  For example to have
> a common solution for platforms.
I did a benchmark on linux and it is about 2% slower on my machine.

I created a new patch where I removed the stat call.
I now calculate the full path name on linux and windows.
This means that soft/hard links do not work any more.
There is still a small slowdown because we create/compare the full path 
name now.
But it is about 0.1% on my 64 bits x86_64 machine. Hard to measure correct.

     Herman



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

[Tinycc-devel] Re : Re: Re : Calling for Release 0.10.0

[david . koch]

Hi Detlef,

I don't care about the "simplicity" of tcc and its supposed goal not to compete 
with larger and more established compilers like gcc or clang.

Tcc still have to be reliable and not falling on simple corner cases because 
someone decided to push a patch on the mob branch, requiring someone else to 
remove it.

I'd like tcc not to be considered just a "quick hack" or a "toy compiler" due 
to its inherent simplicity, it still have to produce correct and reliable code.

Especially since its internals are so "simple", there is no reason tcc couldn't 
be thoroughly tested and stabilized orthogonally across all supported 
architectures.

It's been more than 5 years since the last "stable" release, I'd like the next 
one to be as much "reliable" despite the mob branch will still remain the Wild 
Wide West of salvage patches.

Experimenting is one thing, but regarding the last few months of adventurous 
code modifications and group discussions, I would NOT bet on just numbering the 
current state as being the new 0.10.0.

Let's do a feature freeze first, a comparison checklist with other compilers, 
supporting common flags and attributes, producing correct binary files 
(Windows, Linux, Mac, ...).

Then after a few release candidates, maybe only we could decide the last RC to 
be worthwhile enough to get released with the new official 0.10.0 tags that we 
could feel proud of.

Until then tcc:mob will just remain a nerd's joke and a geek's playground that 
only a few insiders can really use it after great hacking to get it to work 
almost like expected.

Our view on tcc may diverge, but rest assured I like it anyway, I just would 
like it to be treated more fairly and professionally than its original legacy.

Thank you all for putting all such time and passion into its maintenance.

Regards.


- Mail d'origine -
De: wine dev 
À: tinycc-devel@nongnu.org
Envoyé: Mon, 29 May 2023 14:39:17 +0200 (CEST)
Objet: Re: [Tinycc-devel]  Re :  Calling for Release 0.10.0

> [Tinycc-devel] Re :  Calling for Release 0.10.0 – Hi,
>
> the mob branch is pretty much unstable.
>
> Before turning the mob branch into a new release, better do some thorough
> checking and regression testing.
>
> And have something consistent across the various supported platforms (x86,
> AMD64, ARM, M1, RISC-V, ...).
>
> Regards. [...]

Where do you see tcc to be unstable?

Yes, the last patch is ugly and should be removed or fixed
(path is created with alloca and later overwritten with malloc),
and that patch is only used as fallback,
when CONFIG_TCCDIR is undefined.

Primary goals for tcc are:
* Compile to correct code,
* as fast as possible,
* while being as simple as possible


For memory leaks from malloc, which are only freed at program shutdown:
A design decision is not a bug.
* tcc is a short running program,
and a design decission to not free every memory from malloc
is also done by other compiler for speed reasons:
(look at DMC or DMD as examples.)
(i dont know, if both compiler do not free, but i can remember,
 that walter bright wrote, not to free memory was his
 design decision for speed reasons).
* things done in libtcc are different,
as the programm, which is using libtcc might live longer.
I would suggest to fix memory leaks in libtcc.


For using an object format, with is not the same, what most other compiler
use on that system:
A design decision, and not a bug
Disadvantage:
* You can't link object files from other compiler
Advantage:
* simplify the code generator, the linker and probably other tools

This is also done by other compiler for many Years:
* Watcom/OpenWatcom uses OMF
* Embarcadero C++ Builder:
The newer compiler are based on clang
and use ELF object files also on Windows

-​-
Regards ... Detlef


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


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

[Tinycc-devel] Re : Calling for Release 0.10.0

[david . koch]

Hi,

the mob branch is pretty much unstable.

Before turning the mob branch into a new release, better do some thorough 
checking and regression testing.

And have something consistent across the various supported platforms (x86, 
AMD64, ARM, M1, RISC-V, ...).

Regards.


- Mail d'origine -
De: Fred van Kempen via Tinycc-devel 
À: tinycc-devel@nongnu.org
Cc: Fred van Kempen 
Envoyé: Sat, 27 May 2023 02:43:51 +0200 (CEST)
Objet: [Tinycc-devel] Calling for Release 0.10.0

 Grischka:
Please do a version bump to 0.10.0 and a release.
This might help convince people that TCC isn't dead ...
Thanks !!
Fred


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

[Tinycc-devel] Re : transputer arch

[david . koch]

Would probably nice for Atari ATW 800 machines.

Yet would require a native HeliOS version of TCC.

Regards.

- Mail d'origine -
De: David Smith via Tinycc-devel 
À: Tinycc-devel@nongnu.org
Cc: David Smith 
Envoyé: Thu, 06 Apr 2023 09:55:10 +0200 (CEST)
Objet: [Tinycc-devel] transputer arch

HI all,

I’ve been working on the transputer arch for a while and I believe I was close. 
Rebased to latest mob.

https://github.com/agentdavo/tinycc-transputer/ 
 transputer branch

If there are any transputer fans here that have the time to review and or step 
through my code I would be grateful.

It’s been left in non compiling state for a while and not had the chance to fix 
the compiling errors.

A few emulators here

https://github.com/devzendo/transputer-emulator 

https://github.com/pahihu/t4 

-​-
Best regards, David

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

[Tinycc-devel] Re : Re: Re : Is anyone on the C standards committee?

[david . koch]

Oh, yeah, That one :)

I also tried Zig, very nice.

The one that impressed me the most though is Jancy.

Consider this one as the best alternative out there.

And GC can be kept in check, just don't loose control.

Regards.

- Mail d'origine -
De: Steffen Nurpmeso 
À: david koch 
Cc: tinycc-devel@nongnu.org
Envoyé: Wed, 25 Jan 2023 22:26:05 +0100 (CET)
Objet: Re: [Tinycc-devel] Re :  Is anyone on the C standards committee?

david.k...@libertysurf.fr wrote in
 <1115648581.65680975.1674678973317.javamail.r...@zimbra30-e5.priv.proxad\
 .net>:
 ...
 |I think if you want a relatively "stable" yet recent/decent "low level" \
 |programming language might be rust, I guess.

Nim.  (If you really want GC and other such things out of
control.)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


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

[Tinycc-devel] Re : Is anyone on the C standards committee?

[david . koch]

Switch to vlang ?

"C standards committee", let me chuckle a bit. Have you seen what they call 
"standards" ? Bitfield ordering anyone ?

Yeah, C is becoming quite a dumpster of "ideas" and "features", a programming 
language "freak" of many "extensions".

What's rather strange is the constant need to keep C "relevant" while 
maintaining historical "quirks" for "compatibility".

I thought that Python would avoid the same fate, but it has become quite a mess 
too, despite the version 3 "sanitation".

I think if you want a relatively "stable" yet recent/decent "low level" 
programming language might be rust, I guess.

Yet it is nowhere close to the size and speed of TCC, hence I proposed to take 
the vlang route, even though it is alpha.

Regards.

- Mail d'origine -
De: Charles Lohr 
À: tinycc-devel@nongnu.org
Envoyé: Wed, 25 Jan 2023 19:55:00 +0100 (CET)
Objet: [Tinycc-devel] Is anyone on the C standards committee?

I was just wondering if anyone from TCC on the standards committee?  I just
really hope for a compiler as popular as TCC, there's someone there
defending the interests of all the not-GCC, not-clang compilers, where
difficulty of feature addition is a paramount concern.  I use TCC as my
daily driver, and I have been increasingly anxious about some of the
proposals and things that are being added to the C standard.

Charles


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

[Tinycc-devel] Re : Windows distribution/installer

[david . koch]

Hi, nice additiong, you could have used InnoSetup instead though.

I don't really see the point since a portable installation is already quite 
easy to deal with (minus the PATH part).

https://github.com/Kochise/tinycc_win32

The main problem, you have put your finger on, is the age of the current public 
build, and the instability of the current mob branch.

Regards.

- Mail d'origine -
De: Charles Lohr 
À: tinycc-devel@nongnu.org
Envoyé: Wed, 02 Nov 2022 19:57:36 +0100 (CET)
Objet: [Tinycc-devel] Windows distribution/installer

 A few days ago, I started experimenting with just using NSIS to package up
TinyCC as an installer for Windows, which worked out well.  It basically:

* Includes TinyCC Win-64 0.9.27  (Boy would a new release be nice!)
* Includes Win API Headers Full
* Optionally adds TCC (wherever it is installed) to the system path.

A few friends have tested it out and it seems to work for them.

https://github.com/cnlohr/tinycc-win64-installer

A few comments that came up in discussion was:
1) Are there any issues with this?  Is anyone upset by the idea of a
third-party installer?
2) Is it reasonable to have a non-project-sponsored-installer?  Would TCC
be consider making a first party installer instead?
3) It would be really useful to include some sort of Make, even if
primitive.
4) It would be nice to include some common single-file headers.

Since TCC is still a daily driver of mine for some in-work and many
outside-of-work projects, I have a lot of interest in this.  I also do a
lot of C stuff publicly, and people always want to know how to install a C
environment.  I just wanted to get the conversation started, to see if
anyone has any opinions.


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

[Tinycc-devel] Re : Implementing a Global RegisterAllocator for TCC

[david . koch]

Nice, have a look at this repository :

https://github.com/freewilll/wcc

Regards.

- Mail d'origine -
De: Michael Richter 
À: tinycc-devel@nongnu.org
Envoyé: Sat, 06 Aug 2022 08:35:18 +0200 (CEST)
Objet: [Tinycc-devel] Implementing a Global RegisterAllocator for TCC

Did anyone take note of this diplome thesis? It in german, but I guess
there are some germanspekaing here in the list. Author claims 30% speed
up generated code...

Thesis is from 2014, "Implementing a Global RegisterAllocator for TCC",
Sebastian Falbesoner TU Wien (Vienna)

https://www.complang.tuwien.ac.at/Diplomarbeiten/falbesoner14.pdf

Michael Richter


Complete abstract:


Register allocation is a long-standing research topic of computer
science that has been studied extensively over the last decades. Its
goal is to map a theoretically infinite number of program variables onto
a finite, small set of CPU registers during compilation. Eventhough
caches try to bridge the gap between register and memory access time,
keeping asmany values in registers as long as possible is crucial for
good performance. Hence registerallocation is still considered to be one
of the most important compiler optimizations.

The present diploma thesis describes the process of implementing a
register allocatorfor TCC, a small single-pass C compiler written in C.
While TCC is very fast (up to amagnitude faster thangcc -O0for the x86
architecture), it produces code that is quite inefficient – some naive
kind of register allocation is done only on the basis of statements.Our
goal of implementing register allocation done on the basis of whole
functions, that is,global register allocation, should hence result in a
notable performance increase.

As prerequesite for register allocation in TCC, a proper IR
(Intermediate Representation) needs to be generated in a first pass. On
top of this internal representation, livevariable analysis, register
allocation and finally the code generation is then performed. We
determine the variable live intervals with an extraordinarily simple
approach that avoidsthe usual costly data-flow analysis techniques – it
trades off the accuracy of the calculated intervals for higher execution
speed. For the register allocation we use Linear Scan, a strategy that
doesn’t abstract the problem to graph coloring, but rather takes a
simple approachinvolving the linear traversal of variable live
intervals. While linear scan is very fast, it is stated that the
generated code is almost as efficient as with graph coloring, making it
apopular choice for JIT compilers.As target machine, ARM, a classical
RISC architecture, now widespread especially inmobile phones and in many
other embedded systems, is chosen. Since data processing operands must
not reside in memory in thisLoad/Store architecture, register allocation
iseven more important.We determine the performance gain with various
test applications, predominantly fromthe benchmark suiteMiBench.
Additionally, we compare compile-time as well as run-timeperformance
with the widespread compilergcc.The execution time speedup of code
generated by our implementation is about 32% onaverage (compared to the
original TCC), while the compile-time is increased only marginallyand is
still an order of magnitude lower than forgccwithout any optimization.
Conse-quently, our register allocator implementation is an attractive
trade-off for dynamic codegeneration with TCC.


--
__
Aktuelle Lichtmaschinenkunst

http://mir52.wordpress.com



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

[Tinycc-devel] Re : new tcc release

[david . koch]

It's about time, 0.9.27 is more than 4 years old !

Just make sure all opened bugs are fixed.

And update the includes to be more "complete".

You can check my own repo to see what I added as includes.

What's the plan for 1.0 ? Feature set ?

Why focusing on a specific date ("anniversary") for release ?

Regards.


- Mail d'origine -
De: Detlef Riekenberg 
À: tinycc-devel@nongnu.org
Envoyé: Fri, 08 Jul 2022 01:39:43 +0200 (CEST)
Objet: [Tinycc-devel] new tcc release

The last tcc release is very old,
and tcc has received many fixes and new features since then.


What are the plans for a new release?


I vote for a 0.9.28 rc with the current features,
see, what simple fixes are possible
and then make a release in the next weeks.
(Would help distros to include a recent tcc)

Afterwarde prepare for tcc 1.0 later this year.
That would make it possible for distros to add
tcc 1.0 in there spring/LTS releases.

Unfortunately, we missed the 20. anniversary for tcc 1.0
(first commit: 27. Oct. 2001),
but releasing at the 21. anniversary is still possible.


For 1.0, i vote for fixing more bugs and verified C99 support,
either excluding Complex math or
with optional Complex math
(enable during configure, but defaults 'off')

tcc already understand some C11 features
and newer extensions (example: __has_include)
but the related implementation
is missing or buggy (_Atomic)

I would see fixes for C11 things as 'cool, when working',
but optional for tcc 1.0.

What are you think?



-- 
Regards, Detlef



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

[Tinycc-devel] Re : Re: Help with tcc_add_symbol // pe_find_import in 0.9.27

[david . koch]

I maintain a somewhat "up-to-date" Windows version here :

https://github.com/Kochise/tinycc_win32

Go into the /win32 subfolder to get the generated binaries with the 0.9.27 
compiler.

Regards.

- Mail d'origine -
De: Christian Jullien 
À: tinycc-devel@nongnu.org
Envoyé: Tue, 21 Jun 2022 15:50:26 +0200 (CEST)
Objet: Re: [Tinycc-devel] Help with tcc_add_symbol // pe_find_import in 0.9.27

Hello Michael,

 

=> http://download.savannah.gnu.org/releases/tinycc/

 

is really quite old, I doubt you’ll get any help from this list unless you use 
mob https://repo.or.cz/w/tinycc.git

 

C.

 

 

From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Michael Richter
Sent: Tuesday, June 21, 2022 12:38
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] Help with tcc_add_symbol // pe_find_import in 0.9.27

 

Hello,

I'm actually trying to port tcc4tcl from 0.9.26 to 0.9.27. (See 
https://wiki.tcl-lang.org/page/tcc4tcl)

To integrate tcc into tcl there are some changes to be made, especially to the 
Read/Seek part of the loading routines etc., add tcl.h/tclint.h

So far, it seems like I got tcc working, except for one missing link. To 
compile into memory and run the resulting code, wich is why tcc is used in this 
context, you need to transfer the adress of tclStubsPtr (and tclIntStubsPtr) 
into the symboltable with tcc_add_symbol. Under 0.9.26 this worked as expected, 
tcc4tcl added the symbols, the linker resolved them and the resulting code 
executed and found the tclstubs table. Symbols are added in the form 
tcc_add_symbol (s,"tclStubsPtr", tclStubsPtr) where  refers to the 
adress of the internal pointer from the active Tcl Interpreter. the stubstable 
is organized as a list of functionpointers, that are called relative to 
tclStubsPtr (https://wiki.tcl-lang.org/page/Stubs for further info)

 

With 0.9.27 this fails, wether with unkonwn symbol or, if I force tccpe to find 
the symbol, the adress gets resolved in the wrong way and coredumps.

Intersting enough, if I don't compile into memory but use tcc_output_file and 
link against tclStubs86.a all works, so it's not a general problem with linking.

Further Info:

- I used the last 0.9.27 stable from Fabrice Bellard 
http://download.savannah.gnu.org/releases/tinycc/

- I compile and test it under windows (ok, wine to be exact), but use -m32 
WIN32 model to build the tcc4tcl.dll

- Tcl version is 8.6.6

 

Dumping the symboltable shows, that tclStubsPtr and tclIntStubsptr are in 
dynsymtable.

 

pe_find_import refuses to find the symbol, though sym_index >0, because the 
tested conditions are true.

(...)

   sym_index = find_elf_sym(s1->dynsymtab_section, s);
if (sym_index
&& ELFW(ST_TYPE)(sym->st_info) == STT_OBJECT // was stt_object
&& 0 == (sym->st_other & ST_PE_IMPORT)
&& 0 == a
) err = -1, sym_index = 0;

 

(...)

 

 

If I hack this to return the sym_index, the linker will link and the linked 
adress "looks" like it did in 0.9.26, but the resulting code coredumps, so 
something is terribly wrong with this.

 

I can't say, why the symbol gets sorted out. I don't kno, if the coredump comes 
from a false conversion of the pointer adress or if the generated asm is 
handling it wrongly. I'm stuck

 

Is anyone here able to point me in the right direction? Is there a patch im 
missing?

I can put up the modified code on github as a zip if anyone interested in 
getting into the details :-)

Is my problem clear enough or is there any helpful information missing?

 

Michael

 

 



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

[Tinycc-devel] Re : Preprocessor bug: macro eating directives and non nested nested expansions

[david . koch]

> ...that rely on this behavior, e.g.: http://www.kotha.net/bfi/

OMFG, you know it reminds me ?

That : https://www.youtube.com/watch?v=dQppUxTpdzU

- Mail d'origine -
De: camel-cdr via Tinycc-devel 
À: tinycc-devel@nongnu.org
Cc: camel-cdr 
Envoyé: Fri, 17 Jun 2022 14:30:30 +0200 (CEST)
Objet: [Tinycc-devel] Preprocessor bug: macro eating directives and non nested 
nested expansions

Hi, I hope this is the correct place to report this:

1)

#define EAT()
#if 1
EAT
#endif

Results in the error "eat_endif.c:4: error: missing #endif", but the code 
should be valid.

2)

This one is more complicated and not technically a bug, although I don't think 
this behavior is intended.

#define A(x) x B
#define B(x) x A
A(1)(1)(1)(1)

The standard say that it's implementation defined if in the above code the 
macro expansions are nested or not. (see 
https://port70.net/~nsz/c/c11/n1570.html#6.10.3.4p4 and "When a fully 
expanded..." in Annex J)
So an implementation could expand the above either to "1 1 A(1)(1)..." or "1 1 
1 1 A".

gcc, clang, tcc and all otherwise valid preprocessor implementation I know of 
expand it to "1 1 1 1 A", which is great for preprocessor meta programming.

But the problem is, whiles tcc expands the macros as though the expansion isn't 
nested, this isn't reflected in the tcc code.
Meaning, if instead of 4 iterations you have e.g. 2 of them tcc segfaults, 
and the backtrace indicates that it's a stack overflow because of too many 
recursive calls.

The same problem occurs with the following:

#define A0
#define B0
#define A1(x) x B##x(
#define B1(x) x A##x(
A1(1)1)1)1)1)0))


This might sound a bit contrived, but there are preprocessor meta programming 
models that rely on this behavior, e.g.: http://www.kotha.net/bfi/

Greetings,
Olaf

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


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

[Tinycc-devel] Re : Disabling memmove optimization

[david . koch]

What you are requesting when "return b" is indeed a memory move (copy) 
operation.

Since your overriding the C language's memory operations, you have to provide 
your own.

It should be named either "memmove" or "_memmove" provided at link time.

Look for :

"  -nostdincdo not use standard system include paths\n"
"  -nostdlibdo not link with standard crt and libraries\n"

That might be your dope.

https://tinycc-devel.nongnu.narkive.com/9qKgFxHl/nostdlib-option-in-libtcc

https://www.reddit.com/r/kernel/comments/iv9aey/gcc_nostdlib_vs_nolibc/

http://cs107e.github.io/guides/gcc/

Regards.

- Mail d'origine -
De: Raul Hernandez 
À: tinycc-devel@nongnu.org
Envoyé: Tue, 26 Apr 2022 11:04:02 +0200 (CEST)
Objet: [Tinycc-devel] Disabling memmove optimization

Hi, list, 

I’ve noticed that, in some cases, TCC will emit calls to standard library 
functions such as memmove.

For example, the following snippet:


struct Big { void *a, *b, *c; };

struct Big some_function(struct Big b) {
return b;
}


… compiles to something like this (cleaned up for readability; the full 
assembled code can be seen on Godbolt: https://godbolt.org/z/d4nh7oh63 
):

some_function:
push   rbp
movrbp, rsp
subrsp, 0x10
(...)
learsi, [rbp+0x10]
movrdi, QWORD PTR [rbp-0x10]
movedx, 0x18
moveax, 0x0
call   memmove
leave  
ret


I guess TCC does this as either an optimization (to take advantage of 
vectorization in the implementation of memmove), or as a way of simplifying the 
generated code.
My question is: is there any way of disabling this behavior? Ideally I’d wish 
to be able to disable it for a single function, but I’d be happy with a 
compiler flag when invoking TCC or a compile-time define when building it.

***

This probably sounds like the XY problem; the reason why I need to change that 
behavior is that I’m trying to write a closure implementation for the V 
programming language. It works similarly to the approach described in 
https://nullprogram.com/blog/2017/01/08/ 
, but I’m trying to write it in pure 
C for portability (so that it works with any calling convention and number of 
parameters). The implementation works correctly when compiled with GCC and 
clang, but sometimes fails under TCC because of the optimization I described. 
Any function calls within the closure wrapper will become invalid after the 
wrapper is copied somewhere else in memory, since the relative offset to that 
function will be different and the CPU will jump to a garbage location instead. 


Thank you,

Raul



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

[Tinycc-devel] Re : Re: Re : Some questions regarding of TCC's optimizations.

[david . koch]

Have a look : https://github.com/adorad/tcc and https://github.com/adorad/adorad

- Mail d'origine -
De: rempas via Tinycc-devel 
À: Tinycc Devel 
Cc: rem...@tutanota.com, Tinycc Devel 
Envoyé: Tue, 29 Mar 2022 21:12:37 +0200 (CEST)
Objet: Re: [Tinycc-devel]  Re :  Some questions regarding of TCC's 
optimizations.

27 Μαρ 2022, 19:24 Από david.k...@libertysurf.fr:

> Hello Rempas,
>
> writing a compiler is a sport in itself, and there are several different 
> languages out there that are doing a great job.
>
> If you consider C as a low-level candidate, take a look at vlang as well, or 
> Rust, or even Zig.
>
> On the high-level groungtake also a look at Julia (yeah, *that* Julia) or Nim.
>
> But if you ant to go bare metal, prefer to take a look at HLA first (Randall 
> Hyde) :
>
> https://www.randallhyde.com/AssemblyLanguage/HighLevelAsm/index.html
>
> Beare, there's a lot to do before getting a proper optimizing engine.
>
> Prefer take the simple JIT route like TCC, even if the code isn't optimal, 
> CPU caches are large enough to fit small code.
>
> Good luck, but do not over-engineer things upfront.
>
> Regards.
>
Thanks a lot for all the great info! I like vlang a lot but their native 
backend needs TONS of work to be considered useful and be able to compile code. 
I will also look HLA!

Finally, thanks for the last advice! It is very important and I start seeing it 
as I write more and more code. I wish you the best in whatever you do my friend 
;)

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


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

[Tinycc-devel] Re : Some questions regarding of TCC's optimizations.

[david . koch]

Hello Rempas,

writing a compiler is a sport in itself, and there are several different 
languages out there that are doing a great job.

If you consider C as a low-level candidate, take a look at vlang as well, or 
Rust, or even Zig.

On the high-level groungtake also a look at Julia (yeah, *that* Julia) or Nim.

But if you ant to go bare metal, prefer to take a look at HLA first (Randall 
Hyde) :

https://www.randallhyde.com/AssemblyLanguage/HighLevelAsm/index.html

Beare, there's a lot to do before getting a proper optimizing engine.

Prefer take the simple JIT route like TCC, even if the code isn't optimal, CPU 
caches are large enough to fit small code.

Good luck, but do not over-engineer things upfront.

Regards.


- Mail d'origine -
De: rempas via Tinycc-devel 
À: Tinycc Devel 
Cc: rem...@tutanota.com
Envoyé: Sun, 27 Mar 2022 10:34:56 +0200 (CEST)
Objet: [Tinycc-devel] Some questions regarding of TCC's optimizations.

Hi! First of all I would like to say thank you to everyone that has made TCC be 
what it is today! Now, I know and I will not waste anyone's times as our time 
is precious.

So, I want to create a new programming language. Of course there is motivation 
behind this decision but it has nothing to do with this email so anyone who's 
interested can send my a personal email and talk about it. 

I started learning and I get the concept of the frontend well (and I even made 
some small work already)! Now about the backend. I want something that will 
compile the source code FAST. What is my definition of "fast"? Well, GCC is 
slow for my taste!

After making a lot of research (trust me!). I ended up on having the following 
choices:
  1. Output assembly and then use GAS (because of the backend support) and a 
linker to create the final executable/library.
  2. Output machine code and create the object files myself.
  3. Use QBE. Cproc which is a C frontend for QBE, compiles times 4-7 times 
faster than GCC -O2 and has about 70-80% of the runtime performance. So it is 
awesome!!!
  4. TCC

*** THE NEXT TWO PARAGRAPHS CAN BE SKIPPED IF YOU ARE REALLY SHORT IN TIME***
TLTR, 2 is SUPER hard when you want to support multiple OSes and ISAs like I 
want to do. 3 is like a psudo assembly and If I'm about to do this then I 
should as well learn and output assembly, it makes more sense to me given the 
fact that I want fast compile times! I will also have more control as QBE has a 
couple of limitations.

I know a couple of stuff about X86_X64 assembly so I could even make some parts 
of my compiler and have fun! However, something crossed my mind immediately. 
TCC compiles code faster than "GAS" (especially if you add the time needed for 
linking) so why not use TCC instead? I will also have only one dependency in 
this case, which is awesome!

I was thinking about outputting C as the first choice when I decided to truly 
start working into achieving my goal some months ago because of TCC. However, I 
was stopped because the runtime performance (aka code quality) of the code that 
was compiled with TCC. Back then, I didn't knew what optimizations were. Well, 
I knew the word but I didn't knew how compilers do them. Now that I have made 
my research and I know a couple of them, It seems to me that I can do some of 
them in my frontend and use TCC's inline assembly to do a couple of more low 
level ones. So probably I will be able to achieve a compiler that compiles code 
very fast but also has great runtime performance similar to GCC -O2. So it's a 
dream coming true!

However, because I want to make an industry level language that will hold its 
ground and that will be useful, I will need some support and help! To start, I 
want to learn about optimizations on TCC. I heard that TCC doesn't make ANY 
optimizations. Is this true? If no, then what are the optimizations it does? If 
yes, then does this include the ability to inline functions and the "proper" 
register use instead of "push" and "pop" every local variable on the stack. The 
"inline" keyword seems to be ignored based one the "online documentation" but 
the page was last updated in August 2018 and that was 3 and a half years ago so 
I wonder if things have changed.

I'm not very interesting about things like "dead code illumination" or anything 
that requires a lot of time to calculate and profile (and of course a lot of 
work from our end as the profiling code for the compiler will need to be very 
advanced). I think that it's up to the programmer to write code code and not 
have the compiler transform bad code into good code with all the disadvantages 
this brings to the compile times. You like learning and getting better right?

However, I care about the stuff that gives you the 80% of the performance and 
for things that the programmer cannot manually do or decide. So I will like to 
know how low should I go and how many features of TCC I can use. Register usage 
and inlining will be a good start for me. After I learn how 

[Tinycc-devel] Re : Re: TinyCC does not accept variable-length static qualifier for function parameter arrays

[david . koch]

As stated here : https://bellard.org/tcc/

"TCC is heading torward full ISOC99 compliance"

Hence it is recognized as not being fully compliant.

You might want to compare with LCC :

https://drh.github.io/lcc/

The Pelles C compiler is base upon :

http://www.smorgasbordet.com/pellesc/

Regards.

https://en.wikipedia.org/wiki/C99

- Mail d'origine -
De: Michael Matz 
À: tinycc-devel@nongnu.org
Envoyé: Tue, 01 Mar 2022 15:55:08 +0100 (CET)
Objet: Re: [Tinycc-devel] TinyCC does not accept variable-length static 
qualifier for function parameter arrays

Hello,

On Mon, 28 Feb 2022, John Scott wrote:

> On Mon, 2022-02-28 at 09:25 +0100, david.k...@libertysurf.fr wrote:
>> Gcc allows this, but Gcc is not conformant and creates "extensions" as it 
>> see fit.
> This is not a GCC extension; it's my understanding that this is pure
> C99. N2310 [1] (a C17 draft) 6.7.6.3 says
>
> A declaration of a parameter as "array of type" shall be adjusted to
> "qualified pointer to type", where the type qualifiers (if any) are
> those specified within the [ and ] of the array type derivation. If the
> keyword static also appears within the [ and ] of the array type
> derivation, then for each call to the function, the value of the
> corresponding actual argument shall provide access to the first element
> of an array with at least as many elements as specified by the size
> expression.
>
> Correct me if I'm wrong, but isn't argc+1 an expression?

You are correct, it's ISO C and tcc isn't conforming in rejecting this. 
Patches welcome :-)


Ciao,
Michael.

>
> [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2310.pdf
>

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


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

[Tinycc-devel] Re : Re: NULL pointer dereference due to unchecked return from fdopen()

[david . koch]

Nope, I get is as well.

Since I registered to the mailing list.

Regards.

- Mail d'origine -
De: Steffen Nurpmeso 
À: tinycc-devel@nongnu.org
Envoyé: Mon, 28 Feb 2022 21:28:04 +0100 (CET)
Objet: Re: [Tinycc-devel] NULL pointer dereference due to unchecked return from 
fdopen()

Steffen Nurpmeso wrote in
 <20220228202318.dh447%stef...@sdaoden.eu>:
 |Domingo Alvarez Duarte wrote in
 | <0154ffd1-bddf-9093-038a-b8286f92d...@gmail.com>:
 ||+1 To "just write a tcc_fdopen()"
 |
 |Looking into it i thought adding two missing checks is sufficient.
 |Untested.
 |
 |  https://repo.or.cz/tinycc.git/commitdiff/917aad3bcfbb534875aa6d66609bdb3\
 |  6459460a4

Btw for the last couple of mails (as rarely as i post) i get this
auto-responder

  From: nos...@thenerdshow.com
  To: stef...@sdaoden.eu
  Subject: Re: Your mail to nos...@thenerdshow.com
  Message-Id: 
  Date: Mon, 28 Feb 2022 15:23:30 -0500

  ...
  Henry will be available for speaking engagements, consulting, and other work 
anywhere in the United States _after_ September 15.

which is yet another six months?
Have you all blocked this on your firewalls or am i per se alone
with that?

Thanks,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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


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

[Tinycc-devel] Re : TinyCC does not accept variable-length static qualifier for function parameter arrays

[david . koch]

At that moment, the line ain't completely parsed and validated.

Hence argc is still unknown to the compiler.

Gcc allows this, but Gcc is not conformant and creates "extensions" as it see 
fit.

Regards.

- Mail d'origine -
De: John Scott 
À: tinycc-devel@nongnu.org
Envoyé: Mon, 28 Feb 2022 08:06:13 +0100 (CET)
Objet: [Tinycc-devel] TinyCC does not accept variable-length static qualifier 
for function parameter arrays

Hi,

Although this is a conformant C99 program, TinyCC chokes on the
following single line program with 'error: argc undeclared':
int main(int argc, char *argv[static argc+1]) {}

If you're not aware, the static qualifier, when used like this,
indicates that argv must point to an array of at least argc+1 elements.
This can be useful for bounds checking or optimization, but TinyCC
should not fail to compile it. Some other functions this can be useful
with are
int getgroups(int s, gid_t[static s]);
int regexec(const regex_t r[restrict static 1], const char s[restrict 
static 1], size_t n, regmatch_t m[restrict static n], int w);


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

[Tinycc-devel] Re : Re: Re : Re: Re : Re: Extend tcc to use viable.

[david . koch]

Hi, my name is not Steffen :p

Regards.

- Mail d'origine -
De: Domingo Alvarez Duarte 
À: tinycc-devel@nongnu.org
Envoyé: Fri, 25 Feb 2022 19:52:58 +0100 (CET)
Objet: Re: [Tinycc-devel] Re : Re: Re : Re: Extend tcc to use viable.

Hello Steffen !

Thank you for pointing out 
https://directory.fsf.org/wiki/Lightweight_C++ I just downloaded it and 
fixed several compilers warnings/errors but but there is a need to add 
code to handle/ignore "__attribute__" for the preprocessed headers.

I'm making my fixes available here 
https://github.com/mingodad/cfront-3/issues/6

Cheers !

On 25/2/22 15:54, david.k...@libertysurf.fr wrote:
> Yeah, nice project to add some "c++" support to tcc almost for "free".
>
> The dude disappeared after version 1.3.2 in 2008, he perhaps would have 
> improved it some more.
>
> The "instrumentation/decoration" of header files is getting really ridiculous.
>
> I pity the preprocessor sometimes, it might see some really horrible things.
>
> I'm wondering if it doesn't commit suicide during some builds.
>
> Regards.
>
> - Mail d'origine -
> De: Steffen Nurpmeso 
> À: tinycc-devel@nongnu.org
> Envoyé: Fri, 25 Feb 2022 15:15:59 +0100 (CET)
> Objet: Re: [Tinycc-devel]  Re : Re:  Extend tcc to use viable.
>
> david.k...@libertysurf.fr wrote in
>   <1238558077.310183504.1645790418505.javamail.r...@zimbra30-e5.priv.proxa\
>   d.net>:
>   |Try this : https://directory.fsf.org/wiki/Lightweight_C++
>
> Downloaded it and looked, and wow that is overly impressive!
> Some students really go the D. E. Knuth way it seems.
> Making it compile is no hard work, but it seems modern C library
> headers are instrumented so much it cannot grasp them.
> Maybe some day i try to hack it and make that thing work, remove
> exceptions and all that.  _That_ language would really be the C++
> i like!  (At least in practice, my templates have never been
> anything else but typesafe wrappers for generic C types.)
> Of course things tend to become more complicated in real life :)
>
> --steffen
> |
> |Der Kragenbaer,The moon bear,
> |der holt sich munter   he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel

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


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

[Tinycc-devel] Re : Re: Re : Re: Extend tcc to use viable.

[david . koch]

Yeah, nice project to add some "c++" support to tcc almost for "free".

The dude disappeared after version 1.3.2 in 2008, he perhaps would have 
improved it some more.

The "instrumentation/decoration" of header files is getting really ridiculous.

I pity the preprocessor sometimes, it might see some really horrible things.

I'm wondering if it doesn't commit suicide during some builds.

Regards.

- Mail d'origine -
De: Steffen Nurpmeso 
À: tinycc-devel@nongnu.org
Envoyé: Fri, 25 Feb 2022 15:15:59 +0100 (CET)
Objet: Re: [Tinycc-devel]  Re : Re:  Extend tcc to use viable.

david.k...@libertysurf.fr wrote in
 <1238558077.310183504.1645790418505.javamail.r...@zimbra30-e5.priv.proxa\
 d.net>:
 |Try this : https://directory.fsf.org/wiki/Lightweight_C++

Downloaded it and looked, and wow that is overly impressive!
Some students really go the D. E. Knuth way it seems.
Making it compile is no hard work, but it seems modern C library
headers are instrumented so much it cannot grasp them.
Maybe some day i try to hack it and make that thing work, remove
exceptions and all that.  _That_ language would really be the C++
i like!  (At least in practice, my templates have never been
anything else but typesafe wrappers for generic C types.)
Of course things tend to become more complicated in real life :)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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


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

[Tinycc-devel] Re : Re: Extend tcc to use viable.

[david . koch]

Try this : https://directory.fsf.org/wiki/Lightweight_C++

Regards.


- Mail d'origine -
De: Christian Jullien 
À: tinycc-devel@nongnu.org
Envoyé: Fri, 25 Feb 2022 07:27:13 +0100 (CET)
Objet: Re: [Tinycc-devel] Extend tcc to use viable.

Hello Yair,

I only speak for myself but I doubt we will accept an extension to support a 
translator for a DLS that nobody knows.
As you write a translator to C, I'm sure that you can translate to something 
that will implement your behavior (macro, lib, ...). Remember that all C++ 
version up to CFront 3.0 where all C++ => C translators.
I don't think your DLS could be half as much complex as C++ 3.0 was.
A translator has not to be human readable. For example, my OpenLisp compiler, 
which can viewed as OpenLisp to C translator, resembles more to an assembler 
than to a C program. It compiles the complex ISLISP OOP language to a series of 
very basic C instructions and internal lib calls.

Writing a translator/compiler takes time, it took me around 3 months until I 
can translate 80% of OpenLisp and another 3 months to reach 95%. The next 5% 
took me 6 months (not full time). So around one year to be close to 100%. Ten 
years later I still have few bugs with obscure and very uncommon uses. 

M2c

Christian

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Yair Lenga
Sent: Thursday, February 24, 2022 19:39
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] Extend tcc to use viable.

Hi,

I am working on a project to convert a proprietary DSL language into standard 
one. The proprietary language is executed by interpreter engine from intermedia 
representation. The challenge is maintaining the language and the runtime.

I am exploring an option to use compile-on-the-fly approach by translating the 
DSL to c, compile/execute in memory. Language is Fortran/c style, and is “safe” 
(no pointers, atomic strings, and bound-checked arrays) - most statements can 
be converted to c.

One challenge is methods. Language allow simple OO calls obj->method. The 
challenge is how to tell obj->prop (value), vs obj->method (function call). The 
translator can do it, if it will build parse tree, symbol tables. This is much 
more work than a statement by statement translator.

I was hoping it will be possible to make a small change to tcc, introduce a new 
operator (e.g. obj@func), which will be equivalent to obj->method() (function 
call) or obj->prop (member value), based on the type of the member (function 
pointers). Can anyone comment on readability of making such a change to tcc ?

Thanks, yair

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


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


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

[Tinycc-devel] Re : Re: Can a biggener (and idiot) like me read and understand TCC's backend so I can create my own frontend with it?

[david . koch]

Indeed, Pascal is a very good programming language to forces you to be 
organised.

And the 68000 ISA is one of the cleanest out there, not build upon an older one.

You can try Easy68K as an editor and Sim68K as an emulator to run your code :

http://www.easy68k.com/ (source is available)

Then perhaps a full Atari ST emulator (once you master code generation and 
relocation) :

https://github.com/Kochise/atari-emu and https://docs.dev-docs.org/ for 
hard/soft documents

Going the x86 route first is not the most straightforward, it is cumbersome 
with its many quirks.

I'd say 68k -> SH -> MIPS -> ARM -> PPC -> x86 -> AMD64

Regards.

- Mail d'origine -
De: Samir Ribić via Tinycc-devel 
À: jull...@eligis.com, tinycc-devel@nongnu.org
Cc: Samir Ribić 
Envoyé: Sat, 29 Jan 2022 11:41:07 +0100 (CET)
Objet: Re: [Tinycc-devel] Can a biggener (and idiot) like me read and 
understand TCC's backend so I can create my own frontend with it?

I have already sent a tutorial to rempas to make a simple compiler using
parser generator Coco/r, but there is one extremely simple tutorial to
learn writing compilers from scratch: Let's build a compiler by Jack
Crenshaw  Let's Build a Compiler (iecc.com)
 . It is Pascal and Motorola 68000
target based. Do not discard it as obsolete. Pascal is a very readable
programming language, and MC 68000 has a quite good instruction set.

On Sat, Jan 29, 2022 at 11:11 AM Christian Jullien  wrote:

> I suggest you start with something simple:
>
>
>
> A language that implement 4 arithmetic integer operations, has integer
> variables, allows to define functions and includes print function as
> library function.
>
> Chose the syntax you like and start to write you own compiler that
> generate intermediate internal code, then choose a backend (for example C)
> that generates code corresponding to your intermediate code.
>
>
>
> You’ll learn of lot of things and you’ll get 80% of the knowledge you’ll
> need to write serious things.
>
>
>
> This globally how works my Lisp compiler from Lisp files up to standalone
> executable.
>
>
>
> See https://en.wikipedia.org/wiki/OpenLisp#Compiler
>
>
>
> *From:* Tinycc-devel [mailto:tinycc-devel-bounces+eligis=
> orange...@nongnu.org] *On Behalf Of *ian
> *Sent:* Saturday, January 29, 2022 10:43
> *To:* rempas via Tinycc-devel
> *Subject:* Re: [Tinycc-devel] Can a biggener (and idiot) like me read and
> understand TCC's backend so I can create my own frontend with it?
>
>
>
> Hi
>
> One thing or the other :
>
> - you wanna learn asm or algorithmics, and it's not the best place; but
> you obviously need to have to know them a "few",
>
> - or, you already know how to code something in ASM, and then the
> suggested book about how to make an interpreter is the good starting point
> for you.
>
> Rgds
>
> Le 29/01/2022 à 10:08, rempas via Tinycc-devel a écrit :
>
> 29 Ιαν 2022, 03:20 Από s...@conman.org:
>
>
>
> It was thus said that the Great rempas via Tinycc-devel once stated:
>
>
>
> I would advice you to start with this 
> https://craftinginterpreters.com/contents.html first.
>
>
>
> The rest will follow before you know it.
>
>
>
> Thanks! However, I don't understand how this will help me. I mean, I don't
>
> even want to create an intepreter to begin with. So this has nothing to do
>
> with what I want to make. Unless you are referring to the frontend so in
>
> this case, It will probably be a good idea to read this book. Or maybe I
>
> should make an intepreter in the end? Hm
>
>
>
>
>
> It's interpreters all the way down (what do you think CPUs do with machine
>
> code?  They interpret it).  Also, if you have parsed code into a form you
>
> can interpret, you have enough information to generate machine code.
>
>
>
>  -spc
>
>
>
> ___
>
> Tinycc-devel mailing list
>
> Tinycc-devel@nongnu.org
>
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>
>
> I don't know if I'm that stupid but I really don't understand. I know that 
> the CPU interprets the instructions but an interpreter will use a programming 
> language to interpret. For example, the following statement:
>
>
>
> `println("Hello from my lang: {}", "BestLang")`
>
>
>
> will be translated to (suppose the interpreted is written in C) and then be 
> executed:
>
>
>
> `printf("Hello from my lang: %s", "BestLang);`
>
>
>
> So how is this going to teach my assembly and how the instructions are 
> represented in binary? The book specifically says that it won't work with 
> teaching assembly. The interpreted is a binary that takes source code and 
> executes it. It doesn't create a binary. So I really don't understand what's 
> going on here...
>
>
>
> ___
>
> Tinycc-devel mailing list
>
> Tinycc-devel@nongnu.org
>
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
> --
> -- sibian0...@gmail.com
> -- Développeur compulsif
> 

[Tinycc-devel] Re : Making tcc release 0.9.27 with gnu make, musl, and gcc on alpine linux, compilation error occurs

[david . koch]

This legacy version is more than 4 years old, try the up-to-date maintained 
repo :

https://repo.or.cz/tinycc.git

Regards.

- Mail d'origine -
De: squidrin--- via Tinycc-devel 
À: tinycc-devel@nongnu.org
Cc: squid...@tuta.io
Envoyé: Sat, 15 Jan 2022 23:46:37 +0100 (CET)
Objet: [Tinycc-devel] Making tcc release 0.9.27 with gnu make, musl, and gcc on 
alpine linux, compilation error occurs

make[1]: Leaving directory '/home/quin/tcc-0.9.27/lib'
./texi2pod.pl tcc-doc.texi tcc.pod \
&& pod2man --section=1 --center="Tiny C Compiler" --release="0.9.27" tcc.pod > 
tmp.1 \
/bin/sh: ./texi2pod.pl: not found
makeinfo tcc-doc.text || true
/bin/sh: makinfo: not found

I can confirm the existence of 'texi2pod.pl' in my current directory; however, 
it's clearly not an executable file, but rather a perl file. When entering

chmod -x texi2pod.pl

the shell then returns 'Permission denied' in reference to 'texi2pod.pl'. This 
is because the file is not able to be executed (obviously, for those more 
intelligent than me, who wouldn't even think of this).

I downloaded the source code from 
'http://download.savannah.gnu.org/releases/tinycc/', which is the site linked 
directly from Bellard's website.


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


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

[Tinycc-devel] Re : Compile Libbtc for Apple M1 with tcc

[david . koch]

Hi, the M1 chip is an ARM64 processor, not a x86_64 one.

Perhaps the ARM support of TCC is not up to par with its x86 counterpart.

Good luck anyway.

Regards.

- Mail d'origine -
De: Niklas Rosencrantz 
À: tinycc-devel@nongnu.org
Envoyé: Mon, 10 Jan 2022 23:49:04 +0100 (CET)
Objet: [Tinycc-devel] Compile Libbtc for Apple M1 with tcc

Hello,

Trying to compile Libbtc for Apple M1 with tcc. It worked with an Apple
Intel machine and setting CC=tcc. Since tcc can build it on the Intel with
macOS I try ask here if you might know the cause of the failure. With the
Apple M1 the following message comes from make

In file included from ./include/btc/serialize.h:34:
In file included from ./include/btc/portable_endian.h:22:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/libkern/OSByteOrder.h:314:
error: #error Unknown endianess.
make[1]: *** [src/tools/bitcointool-bitcointool.o] Error 1


Build Options:
  with ecmult precomp = yes
  with external callbacks = no
  with benchmarks = yes
  with tests  = yes
  with openssl tests  = no
  with coverage   = no
  module ecdh = no
  module recovery = yes
  module extrakeys= no
  module schnorrsig   = no

  asm = no
  ecmult window size  = 15
  ecmult gen prec. bits   = 4

  valgrind= no
  CC  = tcc
  CFLAGS  = -O2 -fvisibility=hidden -std=c89 -pedantic
-Wall -Wextra -Wcast-align -Wnested-externs -Wshadow -Wstrict-prototypes
-Wundef -Wno-unused-function -Wno-long-long -Wno-overlength-strings -W -g
  CPPFLAGS= -I/opt/homebrew/opt/valgrind/include
  LDFLAGS =

  CC_FOR_BUILD= tcc
  CFLAGS_FOR_BUILD= -O2 -fvisibility=hidden -std=c89 -pedantic
-Wall -Wextra -Wcast-align -Wnested-externs -Wshadow -Wstrict-prototypes
-Wundef -Wno-unused-function -Wno-long-long -Wno-overlength-strings -W -g
  CPPFLAGS_FOR_BUILD  = -I/opt/homebrew/opt/valgrind/include
  LDFLAGS_FOR_BUILD   =

Options used to compile and link:
  with wallet   = yes
  with tools= yes
  with net  = yes

  target os = darwin

  CC= tcc
  CFLAGS= -g -O2 -W -std=gnu99 -pedantic -Wno-unused-function
-Wno-long-long -Wno-overlength-strings -Werror=return-type
  CXX   =
  CXXFLAGS  =
  LDFLAGS   =


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

[Tinycc-devel] Re : IO intensive compilation

[david . koch]

That would mean compiling faster than IO ?

With current SSD speed, I guess it's getting hard.

Perhaps if TCC was multi-threaded and running on a 64 cores threadripper.

But even then, the AMD processor is such a monster you'll hardly make it stall.

Regards.

- Mail d'origine -
De: Chloe Alverti 
À: tinycc-devel@nongnu.org
Envoyé: Wed, 22 Dec 2021 11:59:31 +0100 (CET)
Objet: [Tinycc-devel] IO intensive compilation

Hello to all,

I know that compilation is generally considered CPU bound,
but have you ever encountered a codebase that compilation
was IO-bound?

Best Regards,
Chloe


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

[Tinycc-devel] Re : Re : Re : Re: [BUG] 0.9.28.pre - Cannot link due to : undefined symbol 'main'

[david . koch]

This may be of some help (despite TCC doesn't do C++) :

https://github.com/can1357/linux-pe

- Mail d'origine -
De: david koch 
À: tinycc-devel@nongnu.org
Envoyé: Mon, 22 Nov 2021 22:46:39 +0100 (CET)
Objet: [Tinycc-devel] Re :  Re : Re:  [BUG] 0.9.28.pre - Cannot link due to : 
undefined symbol 'main'

Ok, I took the "SDL_main.c" route.

It works.

Thanks.

Any plan on supporting COFF ?

Regards.

PS : SDL wasn't accepted as a lib, it was a mistake on my side.

- Mail d'origine -
De: david koch 
À: tinycc-devel@nongnu.org
Envoyé: Mon, 22 Nov 2021 18:15:12 +0100 (CET)
Objet: [Tinycc-devel] Re : Re:  [BUG] 0.9.28.pre - Cannot link due to : 
undefined symbol 'main'

Ok-ay, that makes sense. In a way.

Quite strangely, TCC seems to accept SDL as a library though (either as SDL.lib 
or libSDL.a) if you remove the 'def' generation and inclusion during final 
linking.

Will try with SDLmain.c though.

Thank for the feedback.

Regards, David KOCH

- Mail d'origine -
De: grischka 
À: tinycc-devel@nongnu.org
Envoyé: Mon, 22 Nov 2021 17:38:27 +0100 (CET)
Objet: Re: [Tinycc-devel] [BUG] 0.9.28.pre - Cannot link due to : undefined 
symbol 'main'

david.k...@libertysurf.fr wrote:
> 'GLFrontier-win32\src\lib\SDLmain.lib' contains an entry point to 'main'
>
> Yet is not recognized as a library.
>
> 'GLFrontier-win32\src\lib\libSDLmain.a' contains an entry point to 
> 'console_main'
>
> Both contains an entry point to 'WinMain@16', but this is "handled" by SDL.
>
> So, I'm running out of idea how to get this linked.

"SDLmain.lib" and "libSDLmain.a" sounds like pre-made libraries for
usage with MSVC rsp. MINGW-GCC.

Both these binary formats are not compatible with tcc. See also
"tcc-win32.txt -> Limitations".

You'll need to get SDLmain.c and try to compile it from source
using tcc (which may or may not cause additional compilcations ...)

-- gr

>
> Your thought ?
>
> Regards, David KOCH
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel


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


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


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


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

[Tinycc-devel] Re : Re: How many pases tcc doesn? Could we make a faster compiler than tcc for another language?

[david . koch]

I don't understand, could you elaborate a bit ?

Regards.

- Mail d'origine -
De: rempas via Tinycc-devel 
À: Tinycc Devel 
Cc: rem...@tutanota.com, Tinycc Devel 
Envoyé: Mon, 13 Dec 2021 19:41:14 +0100 (CET)
Objet: Re: [Tinycc-devel] How many pases tcc doesn? Could we make a faster 
compiler than tcc for another language?

13 Δεκ 2021, 13:02 Από tonypd...@gmail.com:

> Single pass is not exactly what you think.  The compiler passes over your 
> code once but it keeps track of various things for later resolution.
>
> For example, #define's are macros that are stored in some 'dictionary' to be 
> expanded when actually used, if ever.
>
> It's at the time they are used that they must resolve to something without 
> errors, not during definition.
>
H. Sounds good at thinking but another thing I wonder is how is this 
approach
is in action when trying to implement it as a developer. Not having macros and 
`#include`
and stuff would probably be better. Instead we could have templates that have 
to be
declared before used and then the compiler will see what it needs to generate 
and what
it has already been created. Of course a function will be a little bit slower 
than a macro
that will place the code in place but of course the difference is more tiny 
that TCC ;). `#if`
is the only one that makes sense tbh but it needs to be more powerful of course.


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


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

[Tinycc-devel] Re : Re: How exactly inline works and should I inline all the time?

[david . koch]

Probably in 0.9.27 (which is almost 4 years old, btw -17-Dec-2017 08:27-) :

http://download.savannah.nongnu.org/releases/tinycc/
https://repo.or.cz/tinycc.git ("release_0_9_27" tag)

Yet it officially supports inlined assembly, that also uses the 'inline' 
keyword, hence not completely "ignored".

Anyway, if you look at the tcc source code (tccgen.c, tccpp.c, ...) there is 
already plenty of "inline" inside.

Regards.

- Mail d'origine -
De: Antoni Gual Via 
À: tinycc-devel@nongnu.org
Envoyé: Tue, 07 Dec 2021 09:32:35 +0100 (CET)
Objet: Re: [Tinycc-devel] How exactly inline works and should I inline all the 
time?

Have I missed anything?
The documentation for TCC 0.27 states that the inline keyword is ignored

Antonio



Libre
de virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Missatge de Antonio Prates  del dia dt., 7 de des.
2021 a les 0:35:

> Also note you can't inline recursive functions, and other restrictions
> could apply.
>
> Maybe have a look into this thread on quora:
> https://www.quora.com/Can-a-inline-function-be-recursive
>
> On Dec 6 2021, at 6:23 pm, david.k...@libertysurf.fr wrote:
>
> > Inline is used very specifically where the code has to be fast.
> >
> > Best is only to inline tiny parts of code that will be "inlined".
> >
> > That's to say "injected" into the source code where it is needed.
> >
> > Otherwise it is a full jump to a distant function, with context saving.
> >
> > Hence the "inlining" only serves a very specific purpose.
> >
> > Regards.
> >
> > - Mail d'origine -
> > De: rempas via Tinycc-devel 
> > À: Tinycc Devel 
> > Cc: rem...@tutanota.com
> > Envoyé: Mon, 06 Dec 2021 09:35:19 +0100 (CET)
> > Objet: [Tinycc-devel] How exactly inline works and should I inline all
> > the time?
> >
> > Hi!
> >
> > I don't know if we must only post questions that are specific to the
> > TCC compiler
> > specifically (even tho this question can differ from compiler to
> > compiler) or we can
> > make questions about C in general and in the case that the first is
> > true then please
> > inform me so I know. Anyway I wanted to ask how inline works
> > specifically and not
> > generally. I know generally that it "puts the source code" inline so
> > we don't have to use
> > "jmp" but is there anything else to it that I should know? Are there
> > any dangers or reasons
> > than someone should not use it? Also is there a way to tell the
> > compiler to inline every
> > function rather than always having to add the "inline" keyword?
> >
> > ___
> > Tinycc-devel mailing list
> > Tinycc-devel@nongnu.org
> > https://lists.nongnu.org/mailman/listinfo/tinycc-devel
> >
> >
> > ___
> > Tinycc-devel mailing list
> > Tinycc-devel@nongnu.org
> > https://lists.nongnu.org/mailman/listinfo/tinycc-devel
> >
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>


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

[Tinycc-devel] Re : How exactly inline works and should I inline all the time?

[david . koch]

Inline is used very specifically where the code has to be fast.

Best is only to inline tiny parts of code that will be "inlined".

That's to say "injected" into the source code where it is needed.

Otherwise it is a full jump to a distant function, with context saving.

Hence the "inlining" only serves a very specific purpose.

Regards.

- Mail d'origine -
De: rempas via Tinycc-devel 
À: Tinycc Devel 
Cc: rem...@tutanota.com
Envoyé: Mon, 06 Dec 2021 09:35:19 +0100 (CET)
Objet: [Tinycc-devel] How exactly inline works and should I inline all the time?

Hi!

I don't know if we must only post questions that are specific to the TCC 
compiler
specifically (even tho this question can differ from compiler to compiler) or 
we can
make questions about C in general and in the case that the first is true then 
please
inform me so I know. Anyway I wanted to ask how inline works specifically and 
not
generally. I know generally that it "puts the source code" inline so we don't 
have to use
"jmp" but is there anything else to it that I should know? Are there any 
dangers or reasons
than someone should not use it? Also is there a way to tell the compiler to 
inline every
function rather than always having to add the "inline" keyword?

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


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

[Tinycc-devel] Re : Code generation: `libtcc` vs transpiling to C and then compiling with tcc. Why one over another?

[david . koch]

Hi, what are you trying to achieve ?

MIPS -> x86 ?
MIPS -> C -> tcc -> x86 ?

Or instead of MIPS another language ?

There are several "esoteric" languages that compiles to C, then it's up to you 
using the right compiler for the last mile trip.

Decompiling is a hefty task to do, see my previous request on this list 
(GLFrontier).

While feasible, it's not necessarily the best option.

If you are using an "esoteric" language, it's up to you to produce 
"optimizable" C code that would suit tcc to compile.

Are you doing that at build time or do you plan trying to perform a real-time 
JIT "transpiling" ?

More questions than answers.

Regards.

- Mail d'origine -
De: rempas via Tinycc-devel 
À: tinycc-devel@nongnu.org
Cc: rem...@tutanota.com
Envoyé: Tue, 23 Nov 2021 17:57:49 +0100 (CET)
Objet: [Tinycc-devel] Code generation: `libtcc` vs transpiling to C and then 
compiling with tcc. Why one over another?

Hi! I hope my question is worthy enough so someone spends some time to answer 
me :)

So I want to create a transpiler and I want to use tcc for code generation. So 
I want to
hear opinions about generating code in C and then using tcc (the program) to 
compile
it or using libtcc to generate code. From what I know libtcc exists for cases 
like mine but
from the way that libtcc works, I would still have to convert me code to C so I 
don't find
any advantages. I would also have to deal with other functions as well and with 
the libtcc
API in general so it is also a lot more work to do. Is there something that I 
don't know
about libtcc that makes it worth over using tcc? Thanks in advance!

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


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

[Tinycc-devel] Re : Re : Re: [BUG] 0.9.28.pre - Cannot link due to : undefined symbol 'main'

[david . koch]

Ok, I took the "SDL_main.c" route.

It works.

Thanks.

Any plan on supporting COFF ?

Regards.

PS : SDL wasn't accepted as a lib, it was a mistake on my side.

- Mail d'origine -
De: david koch 
À: tinycc-devel@nongnu.org
Envoyé: Mon, 22 Nov 2021 18:15:12 +0100 (CET)
Objet: [Tinycc-devel] Re : Re:  [BUG] 0.9.28.pre - Cannot link due to : 
undefined symbol 'main'

Ok-ay, that makes sense. In a way.

Quite strangely, TCC seems to accept SDL as a library though (either as SDL.lib 
or libSDL.a) if you remove the 'def' generation and inclusion during final 
linking.

Will try with SDLmain.c though.

Thank for the feedback.

Regards, David KOCH

- Mail d'origine -
De: grischka 
À: tinycc-devel@nongnu.org
Envoyé: Mon, 22 Nov 2021 17:38:27 +0100 (CET)
Objet: Re: [Tinycc-devel] [BUG] 0.9.28.pre - Cannot link due to : undefined 
symbol 'main'

david.k...@libertysurf.fr wrote:
> 'GLFrontier-win32\src\lib\SDLmain.lib' contains an entry point to 'main'
>
> Yet is not recognized as a library.
>
> 'GLFrontier-win32\src\lib\libSDLmain.a' contains an entry point to 
> 'console_main'
>
> Both contains an entry point to 'WinMain@16', but this is "handled" by SDL.
>
> So, I'm running out of idea how to get this linked.

"SDLmain.lib" and "libSDLmain.a" sounds like pre-made libraries for
usage with MSVC rsp. MINGW-GCC.

Both these binary formats are not compatible with tcc. See also
"tcc-win32.txt -> Limitations".

You'll need to get SDLmain.c and try to compile it from source
using tcc (which may or may not cause additional compilcations ...)

-- gr

>
> Your thought ?
>
> Regards, David KOCH
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel


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


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


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

[Tinycc-devel] Re : Re: [BUG] 0.9.28.pre - Cannot link due to : undefined symbol 'main'

[david . koch]

Ok-ay, that makes sense. In a way.

Quite strangely, TCC seems to accept SDL as a library though (either as SDL.lib 
or libSDL.a) if you remove the 'def' generation and inclusion during final 
linking.

Will try with SDLmain.c though.

Thank for the feedback.

Regards, David KOCH

- Mail d'origine -
De: grischka 
À: tinycc-devel@nongnu.org
Envoyé: Mon, 22 Nov 2021 17:38:27 +0100 (CET)
Objet: Re: [Tinycc-devel] [BUG] 0.9.28.pre - Cannot link due to : undefined 
symbol 'main'

david.k...@libertysurf.fr wrote:
> 'GLFrontier-win32\src\lib\SDLmain.lib' contains an entry point to 'main'
>
> Yet is not recognized as a library.
>
> 'GLFrontier-win32\src\lib\libSDLmain.a' contains an entry point to 
> 'console_main'
>
> Both contains an entry point to 'WinMain@16', but this is "handled" by SDL.
>
> So, I'm running out of idea how to get this linked.

"SDLmain.lib" and "libSDLmain.a" sounds like pre-made libraries for
usage with MSVC rsp. MINGW-GCC.

Both these binary formats are not compatible with tcc. See also
"tcc-win32.txt -> Limitations".

You'll need to get SDLmain.c and try to compile it from source
using tcc (which may or may not cause additional compilcations ...)

-- gr

>
> Your thought ?
>
> Regards, David KOCH
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel


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


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

[Tinycc-devel] [BUG] 0.9.28.pre - Cannot link due to : undefined symbol 'main'

[david . koch]

Hi,

using TCC here and there, maintaining a "personal" copy here :

https://github.com/Kochise/tinycc_win32

I was working on compiling GLFrontier with TCC, yet just got :

tcc: error: undefined symbol 'main'

I made some slight changes to the code (like adding Christian Jullien's dirent 
for TCC).

You can find the "fork" here :

https://github.com/Kochise/GLFrontier-win32

1- clone the two repos into the same folder
2- go to 'GLFrontier-win32\src'
3- run 'Makefile-tcc.bat'

You'll get something like :

- - - 8< - - - - - - - - - - - - - - - - - - - - - - - - -
Microsoft Windows [version 10.0.19042.1348]
(c) Microsoft Corporation. Tous droits réservés.

f:\_GIT\GLFrontier-win32\src>Makefile-tcc.bat
 Deleting binaries...

  ::done

 Project settings...

  ::done

 Some flags...

#define __TINYC__ 928
#define __i386__ 1
#define __i386 1
#define _WIN32 1
#define __TCC_PP__ 1
#define __SIZEOF_POINTER__ 4
#define __SIZEOF_LONG__ 4
#define __STDC__ 1
#define __STDC_VERSION__ 199901L
#define __SIZE_TYPE__ unsigned int
#define __PTRDIFF_TYPE__ int
#define __ILP32__ 1
#define __INT64_TYPE__ long long
#define __SIZEOF_INT__ 4
#define __INT_MAX__ 0x7fff
#define __LONG_MAX__ 0x7fffL
#define __SIZEOF_LONG_LONG__ 8
#define __LONG_LONG_MAX__ 0x7fffLL
#define __CHAR_BIT__ 8
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __ORDER_BIG_ENDIAN__ 4321
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __WCHAR_TYPE__ unsigned short
#define __WINT_TYPE__ unsigned short
#define __declspec(x) __attribute__((x))
#define __cdecl
#define __UINTPTR_TYPE__ unsigned __PTRDIFF_TYPE__
#define __INTPTR_TYPE__ __PTRDIFF_TYPE__
#define __INT32_TYPE__ int
#define __BASE_FILE__ "-"
  ::done

 Compiling as68k...

  ::done

 Converting 'fe2.s' in C...

Pass 1
24701 functions generated.
Pass 2
Done! 539337 bytes and 759 relocations.
  ::done
  ::C version remains to be challenged :)

 Compiling virtual machine...

tcc version 0.9.28.pre (i386 Windows)
-> audio.c
<- audio.o
tcc version 0.9.28.pre (i386 Windows)
-> dirent.c
<- dirent.o
tcc version 0.9.28.pre (i386 Windows)
-> hostcall.c
<- hostcall.o
tcc version 0.9.28.pre (i386 Windows)
-> input.c
<- input.o
tcc version 0.9.28.pre (i386 Windows)
-> keymap.c
<- keymap.o
tcc version 0.9.28.pre (i386 Windows)
-> main.c
<- main.o
tcc version 0.9.28.pre (i386 Windows)
-> screen.c
<- screen.o
tcc version 0.9.28.pre (i386 Windows)
-> shortcut.c
<- shortcut.o
  ::done

 Generating definition files...

tcc version 0.9.28.pre (i386 Windows)
-> C:\WINDOWS\SYSTEM32\glu32.dll
<- glu32.def (52 symbols)
tcc version 0.9.28.pre (i386 Windows)
-> f:\_GIT\GLFrontier-win32\src\libvorbisfile.dll
<- libvorbisfile.def (35 symbols)
tcc version 0.9.28.pre (i386 Windows)
-> C:\WINDOWS\SYSTEM32\opengl32.dll
<- opengl32.def (368 symbols)
tcc version 0.9.28.pre (i386 Windows)
-> f:\_GIT\GLFrontier-win32\src\SDL.dll
<- SDL.def (180 symbols)
  ::done

 Generating 'GLFrontier'...

tcc version 0.9.28.pre (i386 Windows)
-> glu32.def
-> libvorbisfile.def
-> opengl32.def
-> SDL.def
-> .\src\audio.o
-> .\src\dirent.o
-> .\src\hostcall.o
-> .\src\input.o
-> .\src\keymap.o
-> .\src\main.o
-> .\src\screen.o
-> .\src\shortcut.o
-> fe2.o
tcc: error: undefined symbol 'main'
  ::Nooo...


f:\_GIT\GLFrontier-win32\src>
- - - 8< - - - - - - - - - - - - - - - - - - - - - - - - -

'GLFrontier-win32\src\lib\SDLmain.lib' contains an entry point to 'main'

Yet is not recognized as a library.

'GLFrontier-win32\src\lib\libSDLmain.a' contains an entry point to 
'console_main'

Both contains an entry point to 'WinMain@16', but this is "handled" by SDL.

So, I'm running out of idea how to get this linked.

Your thought ?

Regards, David KOCH

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