Tiny fix to build-tcc.bat

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

Tiny fix to build-tcc.bat

Joshua Scholar
This is such a simple one-line fix that I'm gonna try mentioning it here instead of forking and pulling.

In the windows build script there this line 23:

if (%2)==(cl) set CC=@call :cl

But this assumes that the Microsoft c compiler is called "cl" when it's officially "CL", so in case the user types the name in upper case, the test should be case-insensitive (which the windows command line is).  So it should be:

if /I (%2)==(cl) set CC=@call :cl

In case you have a sans serif font, that's an upper case i not a lower case L after the slash.

If line 23 fails when it should succeed, then CL is asked to link against tcc.dll, but that compiler wants to be told to link against a lib file, even if the target of that lib file is a dll.  With the "call" in there, it does the right thing.

Josh Scholar

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

Re: JIT compiler efficiency

tinycc-devel mailing list
Hi Joshua


>
> I HAVE made a special version that keeps the include and library directories embedded in the runtime so it doesn't have to read from the disk to use those.  It works but it's not complete and it's not hosted anywhere.  If I keep working on it, I'll fork the source on github.

Is it possible for you to share this work in a github project please?

Does your code statically link libtcc.dll in your test app? 

Which TCC codebase files / functions that relates to loading of the libtcc1-64.a, *.def and include files?

I found that each compilation via JIT, lib\libtcc1-64.a and associated lib\*.def files are getting read each time from the disk. Is it possible to cache these to minimize I/O? Could the compiled versioned of these be reused, rather than compiling/linking each time

>
For my own project, while I could probably add the features I said TCC was missing above, I doubt my ability to add an optimization phase to TCC.
>

In order to have best performance, my plan is to use MSVC (or GCC) for the main application codebase, and use TCC JIT to compile parts of the code that needs to be generated at runtime. Based on the examples\libtcc_test.c its possible to do so and pass function pointers around. What do you think about this approach?


Also, do GCC or MSVC have same JIT capability that TCC provides? Are there any examples anywhere for comparison? I did look into RCC++ however it executes commands to compile and reloads classes - however performance is very slow into 5-10 seconds. I require fast JIT performance. With TCC I am seeing 1-2 milliseconds to JIT compile a very basic function.

Faisal


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

Re: JIT compiler efficiency

Joshua Scholar
I'm working on a fork today, though it won't use zlib, it will have the includes and library files in memory, uncompressed.

If you prefer a compressed version, let me know.  I'm making this one uncompressed for speed and because it will be so much simpler than the compressed version that there may be a chance I can convince the original tiny c project to pull my change into the official tiny c codebase, assuming I can automate its use from make and windows bat files. 

There is a gccjit, and I'm not sure whether it's a full jit or just an in memory compiler for C/C++ like tcc. 

Keep in mind that the GCC codebase has a full GNU license and can't be included in a non-open sourced program at all.

Msvc does not have a jit. 

On Wed, Dec 30, 2020 at 11:39 AM [hidden email] <[hidden email]> wrote:
Hi Joshua


>
> I HAVE made a special version that keeps the include and library directories embedded in the runtime so it doesn't have to read from the disk to use those.  It works but it's not complete and it's not hosted anywhere.  If I keep working on it, I'll fork the source on github.

Is it possible for you to share this work in a github project please?

Does your code statically link libtcc.dll in your test app? 

Which TCC codebase files / functions that relates to loading of the libtcc1-64.a, *.def and include files?

I found that each compilation via JIT, lib\libtcc1-64.a and associated lib\*.def files are getting read each time from the disk. Is it possible to cache these to minimize I/O? Could the compiled versioned of these be reused, rather than compiling/linking each time

>
For my own project, while I could probably add the features I said TCC was missing above, I doubt my ability to add an optimization phase to TCC.
>

In order to have best performance, my plan is to use MSVC (or GCC) for the main application codebase, and use TCC JIT to compile parts of the code that needs to be generated at runtime. Based on the examples\libtcc_test.c its possible to do so and pass function pointers around. What do you think about this approach?


Also, do GCC or MSVC have same JIT capability that TCC provides? Are there any examples anywhere for comparison? I did look into RCC++ however it executes commands to compile and reloads classes - however performance is very slow into 5-10 seconds. I require fast JIT performance. With TCC I am seeing 1-2 milliseconds to JIT compile a very basic function.

Faisal


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

Re: JIT compiler efficiency

tinycc-devel mailing list
Thank you Joshua

Uncompressed will be fine for now as I am still experimenting. When you have compressed version please do share. Does it read from filesystem and then cache, or just embeds all files as resources. With this codebase, do you have a sample .c code which this working that I can experiment with? Also, is your codebase based on TCC 0.9.27 or the current GIT master?

Since you mentioned licensing, can TCC be embedded inside a non-open source program?

----
On Wednesday, 30 December 2020, 20:54:19 GMT, Joshua Scholar <[hidden email]> wrote:


I'm working on a fork today, though it won't use zlib, it will have the includes and library files in memory, uncompressed.

If you prefer a compressed version, let me know.  I'm making this one uncompressed for speed and because it will be so much simpler than the compressed version that there may be a chance I can convince the original tiny c project to pull my change into the official tiny c codebase, assuming I can automate its use from make and windows bat files. 

There is a gccjit, and I'm not sure whether it's a full jit or just an in memory compiler for C/C++ like tcc. 

Keep in mind that the GCC codebase has a full GNU license and can't be included in a non-open sourced program at all.

Msvc does not have a jit. 

On Wed, Dec 30, 2020 at 11:39 AM [hidden email] <[hidden email]> wrote:
Hi Joshua


>
> I HAVE made a special version that keeps the include and library directories embedded in the runtime so it doesn't have to read from the disk to use those.  It works but it's not complete and it's not hosted anywhere.  If I keep working on it, I'll fork the source on github.

Is it possible for you to share this work in a github project please?

Does your code statically link libtcc.dll in your test app? 

Which TCC codebase files / functions that relates to loading of the libtcc1-64.a, *.def and include files?

I found that each compilation via JIT, lib\libtcc1-64.a and associated lib\*.def files are getting read each time from the disk. Is it possible to cache these to minimize I/O? Could the compiled versioned of these be reused, rather than compiling/linking each time

>
For my own project, while I could probably add the features I said TCC was missing above, I doubt my ability to add an optimization phase to TCC.
>

In order to have best performance, my plan is to use MSVC (or GCC) for the main application codebase, and use TCC JIT to compile parts of the code that needs to be generated at runtime. Based on the examples\libtcc_test.c its possible to do so and pass function pointers around. What do you think about this approach?


Also, do GCC or MSVC have same JIT capability that TCC provides? Are there any examples anywhere for comparison? I did look into RCC++ however it executes commands to compile and reloads classes - however performance is very slow into 5-10 seconds. I require fast JIT performance. With TCC I am seeing 1-2 milliseconds to JIT compile a very basic function.

Faisal

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

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

Re: JIT compiler efficiency

Joshua Scholar
I had a version that embeds a zip file before having an uncompressed one.
It just seemed to me that it was asking a lot of the TCC project to include zlib and a new version of minizip/miniunzip and figure out how to build that on all systems.
I can just make a git with that, which has those projects and a microsoft solution that builds a static linkable unzip library to link in, it's just that it feels a bit weird to throw a bunch of different libraries together and upload all of their directories as one project.

On Wed, Dec 30, 2020 at 1:07 PM fm663-subs--- via Tinycc-devel <[hidden email]> wrote:
Thank you Joshua

Uncompressed will be fine for now as I am still experimenting. When you have compressed version please do share. Does it read from filesystem and then cache, or just embeds all files as resources. With this codebase, do you have a sample .c code which this working that I can experiment with? Also, is your codebase based on TCC 0.9.27 or the current GIT master?

Since you mentioned licensing, can TCC be embedded inside a non-open source program?

----
On Wednesday, 30 December 2020, 20:54:19 GMT, Joshua Scholar <[hidden email]> wrote:


I'm working on a fork today, though it won't use zlib, it will have the includes and library files in memory, uncompressed.

If you prefer a compressed version, let me know.  I'm making this one uncompressed for speed and because it will be so much simpler than the compressed version that there may be a chance I can convince the original tiny c project to pull my change into the official tiny c codebase, assuming I can automate its use from make and windows bat files. 

There is a gccjit, and I'm not sure whether it's a full jit or just an in memory compiler for C/C++ like tcc. 

Keep in mind that the GCC codebase has a full GNU license and can't be included in a non-open sourced program at all.

Msvc does not have a jit. 

On Wed, Dec 30, 2020 at 11:39 AM [hidden email] <[hidden email]> wrote:
Hi Joshua


>
> I HAVE made a special version that keeps the include and library directories embedded in the runtime so it doesn't have to read from the disk to use those.  It works but it's not complete and it's not hosted anywhere.  If I keep working on it, I'll fork the source on github.

Is it possible for you to share this work in a github project please?

Does your code statically link libtcc.dll in your test app? 

Which TCC codebase files / functions that relates to loading of the libtcc1-64.a, *.def and include files?

I found that each compilation via JIT, lib\libtcc1-64.a and associated lib\*.def files are getting read each time from the disk. Is it possible to cache these to minimize I/O? Could the compiled versioned of these be reused, rather than compiling/linking each time

>
For my own project, while I could probably add the features I said TCC was missing above, I doubt my ability to add an optimization phase to TCC.
>

In order to have best performance, my plan is to use MSVC (or GCC) for the main application codebase, and use TCC JIT to compile parts of the code that needs to be generated at runtime. Based on the examples\libtcc_test.c its possible to do so and pass function pointers around. What do you think about this approach?


Also, do GCC or MSVC have same JIT capability that TCC provides? Are there any examples anywhere for comparison? I did look into RCC++ however it executes commands to compile and reloads classes - however performance is very slow into 5-10 seconds. I require fast JIT performance. With TCC I am seeing 1-2 milliseconds to JIT compile a very basic function.

Faisal

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

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

Re: JIT compiler efficiency

tinycc-devel mailing list
Joshua, seems like you have done quite a lot with TCC. I look forward to the repo once you upload.

The files are not that large anyway. Also uncompressed one may actually be of similar size to, compressed + statically linked zlib size.

Also uncompressed ones are likely to be more managable and portable.

-----
On Wednesday, 30 December 2020, 23:39:59 GMT, Joshua Scholar <[hidden email]> wrote:


I had a version that embeds a zip file before having an uncompressed one.
It just seemed to me that it was asking a lot of the TCC project to include zlib and a new version of minizip/miniunzip and figure out how to build that on all systems.
I can just make a git with that, which has those projects and a microsoft solution that builds a static linkable unzip library to link in, it's just that it feels a bit weird to throw a bunch of different libraries together and upload all of their directories as one project.

On Wed, Dec 30, 2020 at 1:07 PM fm663-subs--- via Tinycc-devel <[hidden email]> wrote:
Thank you Joshua

Uncompressed will be fine for now as I am still experimenting. When you have compressed version please do share. Does it read from filesystem and then cache, or just embeds all files as resources. With this codebase, do you have a sample .c code which this working that I can experiment with? Also, is your codebase based on TCC 0.9.27 or the current GIT master?

Since you mentioned licensing, can TCC be embedded inside a non-open source program?

----
On Wednesday, 30 December 2020, 20:54:19 GMT, Joshua Scholar <[hidden email]> wrote:


I'm working on a fork today, though it won't use zlib, it will have the includes and library files in memory, uncompressed.

If you prefer a compressed version, let me know.  I'm making this one uncompressed for speed and because it will be so much simpler than the compressed version that there may be a chance I can convince the original tiny c project to pull my change into the official tiny c codebase, assuming I can automate its use from make and windows bat files. 

There is a gccjit, and I'm not sure whether it's a full jit or just an in memory compiler for C/C++ like tcc. 

Keep in mind that the GCC codebase has a full GNU license and can't be included in a non-open sourced program at all.

Msvc does not have a jit. 

On Wed, Dec 30, 2020 at 11:39 AM [hidden email] <[hidden email]> wrote:
Hi Joshua


>
> I HAVE made a special version that keeps the include and library directories embedded in the runtime so it doesn't have to read from the disk to use those.  It works but it's not complete and it's not hosted anywhere.  If I keep working on it, I'll fork the source on github.

Is it possible for you to share this work in a github project please?

Does your code statically link libtcc.dll in your test app? 

Which TCC codebase files / functions that relates to loading of the libtcc1-64.a, *.def and include files?

I found that each compilation via JIT, lib\libtcc1-64.a and associated lib\*.def files are getting read each time from the disk. Is it possible to cache these to minimize I/O? Could the compiled versioned of these be reused, rather than compiling/linking each time

>
For my own project, while I could probably add the features I said TCC was missing above, I doubt my ability to add an optimization phase to TCC.
>

In order to have best performance, my plan is to use MSVC (or GCC) for the main application codebase, and use TCC JIT to compile parts of the code that needs to be generated at runtime. Based on the examples\libtcc_test.c its possible to do so and pass function pointers around. What do you think about this approach?


Also, do GCC or MSVC have same JIT capability that TCC provides? Are there any examples anywhere for comparison? I did look into RCC++ however it executes commands to compile and reloads classes - however performance is very slow into 5-10 seconds. I require fast JIT performance. With TCC I am seeing 1-2 milliseconds to JIT compile a very basic function.

Faisal

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel