Re: [Tinycc-devel] Tinycc-devel Digest, Vol 192, Issue 12

[KHMan]

On 5/21/2019 4:08 AM, Ben Hutchinson wrote:

Date: Sun, 19 May 2019 01:11:26 +0200
From: Daniel Gl?ckner mailto:daniel...@gmx.net>>

If you don't need __chkstk, you are not compiling for Windows
and should
not use a TinyCC that is targetting Windows. TinyCC targetting
Linux does
not emit calls to __chkstk.


[snip snip snip]
If the official TinyCC developers were to make this one simple 
change, TinyCC would no longer be a no-go for me, and in fact 
TinyCC would then become my primary means to write Windows software.


It's quite puzzling to see this sort of request.

I agree with Austin that if the feature is so important, then 
consider patching it yourself. It is easier to compile tcc 
yourself and tweak whatever you want versus gcc. Or maybe use gcc -O0?


If you plan to write Windows software in C, I think assembly 
output doesn't really matter for most devs. For CPUs now cache 
misses are like train wrecks that limits max perf. Even how your 
executable is aligned when loaded may have big effects on 
performance. I just trust the compiler to do its thing. Install 
MinGW or MSYS2 and use gcc, apply whatever compiler options that 
are appropriate.


For modern PCs, I guess most devs still doing heavy-duty assembly 
are for math performance or multimedia performance. And x86_64 
skills may be more important nowadays than x86 skills.


Even for embedded programming, there is usually zero need to think 
in assembly. Use the appropriate syntax and intrinsics and one can 
write C code quickly and productively without ever needing to 
remember CPU instruction mnemonics.


IMHO, to productively write Windows software in C, just think in 
C. I'm curious as to why you have this unusual need.



--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia


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

Re: [Tinycc-devel] TCC and ARM instruction set

[KHMan]

On 5/7/2018 3:44 PM, Yakov wrote:
I read OP's question differently, it seemed he wanted to know more 
about the intrinsics of TinyCC in regards to various instruction 
set supports rather than to know more about ARM technology in 
general? OR maybe "how advanced is the support of ARM in TCC"? If 
it was worded as "how do you add a new instruction set to TCC in 
three easy steps" I'd also want to read the answer btw :)


Well, that's one interpretation. And there may be language 
impediments. But look back at the last two threads OP initiated. 
On the balance it looks more like he has product or tool ideas... 
but wants a tcc ready for incorporation into the product or tool.


Notice he did not continue the thread requesting for 
implementation guidance, or coding guidance.


On another note, here's another arch update for OP: MIPS just 
announced nanoMIPS the other day. :-)




2018-04-26 18:20 GMT+03:00 KHMan :

On 4/26/2018 10:31 PM, Ulrich Althöfer wrote:

Dear Developers,
I am interested to hear more about the state of
implementing the ARM instruction set.

- Are there different levels of developing states between
the 16 bit (Thumb) and 32 bit instruction set?
- Is there a hardware abstraction level (HAL) built in the
Tiny C Compiler?
- Are there documents about this subject?


See this intro: https://en.wikipedia.org/wiki/ARM_Cortex-M
<https://en.wikipedia.org/wiki/ARM_Cortex-M>

It's like the IA32/x64 instruction set these days, there are a
lot of different sets of instructions and this and that. What
do you want to target? That is the question. All? Then the
problem is complexity and scope.

If you want to target IoT parts, say they use Cortex-M4F, then
you need to support a bunch of stuff. Supporting a newer arch
will require supporting other stuff. You kinda need a arch
infrastructure to keep track of all these things. SAM parts
all say Cortex-M0+ in their datasheets (that I've read
anyway), but M0+ is only for the traditional small MCUs.

Anyway, for a C user like me who rarely dip into assembly,
it's hard to keep track of all this proficiently. Successful
chip architectures with lots of legacy baggage need a bit of
effort to learn.


- How expensive is it to implement the Thumb code?


Projects such as tcc are resource-starved. I'm a lurker, I
code other stuff, but I'm sure coders are welcome here. There
are no troops to rally. It's more roll up your sleeves and dig in.


- Isn't it a challenge to implement the 'tiny' Thumb
instruction set, because ARM is the overwhelming dominant
embedded processor architecture nowadays?


Not all embedded users need Thumb instructions. The ARM arch
has different 'modes' targeted towards different market segments.

If you want to be on the leading edge of something, why not do
RISC-V instead?


I am glad to hear about the intentions of implementing.

Greetings from Germany
Ulrich
[snip]


--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia


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

Re: [Tinycc-devel] TCC and ARM instruction set

[KHMan]

On 4/26/2018 10:31 PM, Ulrich Althöfer wrote:

Dear Developers,
I am interested to hear more about the state of implementing the 
ARM instruction set.


- Are there different levels of developing states between the 16 
bit (Thumb) and 32 bit instruction set?
- Is there a hardware abstraction level (HAL) built in the Tiny C 
Compiler?

- Are there documents about this subject?


See this intro: https://en.wikipedia.org/wiki/ARM_Cortex-M

It's like the IA32/x64 instruction set these days, there are a lot 
of different sets of instructions and this and that. What do you 
want to target? That is the question. All? Then the problem is 
complexity and scope.


If you want to target IoT parts, say they use Cortex-M4F, then you 
need to support a bunch of stuff. Supporting a newer arch will 
require supporting other stuff. You kinda need a arch 
infrastructure to keep track of all these things. SAM parts all 
say Cortex-M0+ in their datasheets (that I've read anyway), but 
M0+ is only for the traditional small MCUs.


Anyway, for a C user like me who rarely dip into assembly, it's 
hard to keep track of all this proficiently. Successful chip 
architectures with lots of legacy baggage need a bit of effort to 
learn.




- How expensive is it to implement the Thumb code?


Projects such as tcc are resource-starved. I'm a lurker, I code 
other stuff, but I'm sure coders are welcome here. There are no 
troops to rally. It's more roll up your sleeves and dig in.



- Isn't it a challenge to implement the 'tiny' Thumb instruction 
set, because ARM is the overwhelming dominant embedded processor 
architecture nowadays?


Not all embedded users need Thumb instructions. The ARM arch has 
different 'modes' targeted towards different market segments.


If you want to be on the leading edge of something, why not do 
RISC-V instead?




I am glad to hear about the intentions of implementing.

Greetings from Germany
Ulrich



--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia



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

Re: [Tinycc-devel] Joining Tiny C Compiler with ItsyBitsy M0 Express

[KHMan]

On 4/21/2018 12:45 AM, Ulrich Althöfer wrote:

Dear Developers,
is it possible to implement the TCC on an awsome microcontroller 
board?


If you want to compile on the MCU itself, then data RAM will be an 
issue. See MicroPython FAQ here:


  https://github.com/micropython/micropython/wiki/FAQ

So 32KB will still be an issue for any non-trivial MicroPython 
script. See any number of forum postings on people running smack 
into this. If "tcc compile on MCU" inconveniences coders, then it 
will hurt adoption. Then for tcc you will need to expend effort on 
on-chip memory usage issues, or mitigate with library linking or 
dynamic linking.


Next, if you plan to target beginners and grow a community, you 
are up against a whole horde of similar beginner-MCU-board 
initiatives. Some might even have corporate (Sparkfun, AdaFruit 
and others are all eyeing the education pie) or crowdfunding 
backing. Assume you want to 'sell' tcc to beginners. Who are you 
targeting, what skill level, what age, etc. If you target 
experienced coders, then they will measure the thing versus their 
usual toolchain. For example, I for one have zero urge to move 
from my usual C toolchains to MicroPython -- I already have 
thousands of lines of working code that I can draw from. So the 
target demographic can be an issue.


Also, I have not come across any MicroPython projects during 
casual browsing on electronics projects -- it has not lit up the 
scene like Arduino (whose popularity may be partly due to many 
libraries and a lot of code that folks can cut and paste). Where 
are all the non-trivial projects done with MicroPython? I don't 
remember coming across any.


This is not to say it's a bad idea, but there may be significant 
barriers or issues, depending on your objectives. Also, early 
adoptees might not appear unless you already have a prototype that 
works and is useful -- often someone has to do the initial 
implementation.



I am fascinated by the very compact microcontroller board 
'ItsyBitsy M0 Express'. It is equipped with the ARM Cortex M0+ 
processor (with 256KB Flash and 32 KB RAM builtin) running at 48 
MHz and 2 MB SPI FLASH on board - hence called 'Express'. The USB 
board is developed by Adafruit Industries (Owner 'Ladyada'). Look 
at the website:

https://www.adafruit.com/product/3727

The particular feature of the ItsyBitsy is in my opinion the 
builtin Python interpreter in combination with the external 
accessible FAT file system. The USB interface is implemented 
native - without a separate processor. The Python interpreter is 
condensed to 'MicroPython'. The 'CircuitPython' is Adafruit's open 
source derivative of MicroPython especially prepared for Atmels 
ARM M0 type 'SAMD21'. Although the CircuitPython interpreter runs 
in this little ARM chip it shows 19696 bytes of free memory.


The intended benefits of joining the TCC with the ItsyBitsy:
- Faster execution time than with the Python interpreter.
- Better energy efficiency because of direct command execution.
- Better deterministic characteristic.
- C as an additional educational language to Python.
- The self-contained C source (equivalent to the interpreter 
version).


The last point (the self-contained C source) on such a compact 
embedded board is very fun, because you get independent from the 
usual Operating Systems, proprietary chains and local situations: 
just pull the USB board off and you have the whole development 
information with you.


Let's do IT:
- Information Technology
- Interdisciplinary Thinking

P.S.
Actually the ItsyBitsy M4 Express is advertised.
The ARM CORTEX M4 with 192k of RAM and 512k flash @ 120 MHz is 
builtin.


Greetings from Germany
Ulrich



--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia


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

Re: [Tinycc-devel] tcc and slang cooperation

[KHMan]

On 3/27/2018 4:58 PM, Agathoklis D.E Chatzimanikas wrote:

[snip]
I'm going soon to start to try to write a slang interpeter with an embeddable
tcc dynamical C interpeter.


"dynamical C interpeter" is incorrect.

Have fun, happy hacking.

--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia


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

Re: [Tinycc-devel] "_winstart not defined"

[KHMan]

On 2/10/2018 5:07 PM, Daemon Magic wrote:
Try to use your mingw-built tcc to compile your test.c example, if 
it compiles w/o errors, your tcc built with itself has some problems.


I don't have any experience using a Win32 tcc, so I'll leave it to 
those who have done so to respond. If there is a symbol missing, I 
tend to think it is a header file or linker issue.


That said, tcc version 0.9.27 was released on Dec 17, 2017, and it 
appears that there are Windows executables available in the 
download section:


https://savannah.nongnu.org/projects/tinycc



2018-02-10 7:09 GMT+02:00 k2tom:

My original "current release" of 0.9.25 came from
tcc-0.9.25.tar.bze
(5/20/2009).  (This has the sources.. but NOT the binaries.) 
I used MinGW

to build TCC from those sources.  Then I used this
newly-minted TCC to build
a newer TCC from the sources.  (I just wanted to verify that
one could in
fact use TCC to compile ITSELF.)

The program I'm trying to compile is test.c, take verbatim
from the Forger's
Tutorial.  And the exact command line I'm using is:

prompt> *tcc -o test.exe test.c -mwindows*
tcc: _winstart not defined

Tom



--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia



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

Re: [Tinycc-devel] "_winstart not defined"

[KHMan]

On 2/9/2018 10:56 PM, Daemon Magic wrote:

Hi, what is exact command line you're trying to exec?


It is better to reply to k2tom/Tom's original e-mail, since I 
snipped some things out.


Tom should also tell us where the tcc binaries came from, note 
that he mentioned "(0.9.25+)" in the first para.




2018-02-07 18:57 GMT+02:00 KHMan :

On 2/8/2018 12:19 AM, k2tom wrote:
[snip snip]

I was "just curious" and I tried using TinyCC to build the
Windows
"applications" from the "Forger's Win32API Tutorial" (a
great (imo)
introduction to Win32 programming).  (Normally I use
Cygwin GCC and/or MinGW
GCC to build these example programs.  But to get them to
compile under
Cygwin GCC, I had to use the -mno-cygwin switch.. and
that's been depricated
in Cygwin GCC.. so I'm left with only MinGW.)


I suspect they'd point you to the MinGW cross compiler
packages, see:

https://cygwin.com/cgi-bin2/package-grep.cgi?grep=mingw64=x86
<https://cygwin.com/cgi-bin2/package-grep.cgi?grep=mingw64=x86>

(I haven't used it. I use MinGW/MSYS, MSYS2, TDM-gcc, Cygwin gcc.)

But when I try building these examples with TinyCC, I get
a "_winstart not
defined" error.  Any hints/ideas?



--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia



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

Re: [Tinycc-devel] "_winstart not defined"

[KHMan]

On 2/8/2018 12:19 AM, k2tom wrote:
[snip snip]

I was "just curious" and I tried using TinyCC to build the Windows
"applications" from the "Forger's Win32API Tutorial" (a great (imo)
introduction to Win32 programming).  (Normally I use Cygwin GCC and/or MinGW
GCC to build these example programs.  But to get them to compile under
Cygwin GCC, I had to use the -mno-cygwin switch.. and that's been depricated
in Cygwin GCC.. so I'm left with only MinGW.)


I suspect they'd point you to the MinGW cross compiler packages, see:

https://cygwin.com/cgi-bin2/package-grep.cgi?grep=mingw64=x86

(I haven't used it. I use MinGW/MSYS, MSYS2, TDM-gcc, Cygwin gcc.)


But when I try building these examples with TinyCC, I get a "_winstart not
defined" error.  Any hints/ideas?



--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia


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

Re: [Tinycc-devel] c89

[KHMan]

On 9/27/2017 11:14 AM, Larry Doolittle wrote:

Friends -

On Tue, Sep 26, 2017 at 03:49:09PM -0700, Larry Doolittle wrote:

Someone asked about c89.  I made a simple experiment on mob.
1.  Replace 67 //-style comments with /* */
2.  #define inline __inline__ in tcc.h
3.  Use --std=c89 under gcc-4.9.2 on x86_64
The result builds and passes self-tests.


I went through the tcc compile with --std=c89 -pedantic and
--std=c99 -pedantic options.  That flagged the "long long" feature
mentioned already, plus a bunch more potential barriers to strict
c89 or even c99 compilers.

Does someone have a concrete example of a c89 compiler they hope to
boostrap from?  Preferably one that can be downloaded and run (maybe in
an emulator) without payment.  For bootstrapping purposes, there are many
workarounds that can be considered that might not fly for a production
compiler.


+1

--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia


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

Re: [Tinycc-devel] Using tinycc for full source bootstrapping

[KHMan]

On 9/27/2017 10:26 AM, Michael B. Smith wrote:

As I read your comments, especially these:


I would find it awesome if tinycc would restrict its source to C89.


2017 - 1989 = 28.

Twenty-Eight Years. It would be kinda nice to move forward. Will we stick to 
C89 simply because of certain platforms that may never move forward? It's kinda 
like tying stones to one's legs. Or a lowest common denominator scenario.


You were suggesting to abandon the "old" or "legacy" support.


Context.

The discussion was on tcc bootstrapping.

The question I was posing was whether tcc should be tied to a 
commitment to a 28 year old standard.


English can be a very ambiguous language. A tiny thought can lead 
to tunnel vision down one of many supposedly plausible paths.




If I misunderstood, please forgive me.

-Original Message-
From: Tinycc-devel On Behalf Of KHMan
Sent: Tuesday, September 26, 2017 10:18 PM
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Using tinycc for full source bootstrapping
[snipped everything]



--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia


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

Re: [Tinycc-devel] Using tinycc for full source bootstrapping

[KHMan]

On 9/27/2017 9:54 AM, Michael B. Smith wrote:

You funny.

I've still got hundreds of thousands of lines of C in K C. In production. 
Supporting major applications.

You are obviously one of those people who thinks that COBOL is ancient and 
unused, aren't you?

Because I've got millions of production LOC in COBOL.

No offense, but I don't think you understand the real world.


Please look at this line from Rune:
"Compilers written in C89 and understanding C99 hardly exist."

This implies that his intention is to get C99 via a C89 route.

If his ending point is a C99 capable tcc and natively hosted, then 
it has nothing to do with any amount of legacy code, which can 
continue to use legacy compilers. I say certain platforms may 
never move forward because in those cases we are usually at the 
mercy of proprietary compilers and the companies that make them.


We are not talking about a C89 end point here. C89 folks continue 
to use their stuff, I'm sure it will be in use past 2100. No 
problem with that. tcc was already using // comments with nary an 
outcry for like ages. When was it ever a problem? The only problem 
this time is that someone wants to bootstrap without any tiny bit 
of any kind of cross compiling variations.


No offense, but I don't think I have been out of line.


-Original Message-
From: Tinycc-devel On Behalf Of KHMan
Sent: Tuesday, September 26, 2017 9:41 PM
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Using tinycc for full source bootstrapping

On 9/27/2017 5:30 AM, u-j...@aetey.se wrote:

On Sun, Sep 24, 2017 at 07:40:32PM +0200, grischka wrote:

Also as source tcc is supposed to be C89, except maybe 'long long'
and maybe some minor things here or there which we could change
indeed if that is wanted (for example usage of compound initializers
in arm-gen.c)


[not a tinycc developer but using / depending on compiler
bootstrapping]

I would find it awesome if tinycc would restrict its source to C89.


2017 - 1989 = 28.

Twenty-Eight Years. It would be kinda nice to move forward. Will we stick to 
C89 simply because of certain platforms that may never move forward? It's kinda 
like tying stones to one's legs. Or a lowest common denominator scenario.


Compilers written in C89 and understanding C99 hardly exist. This
makes it hard to do a proper bootstrap from the ground with minimal
dependency on existing binaries.


Could you give an example/examples where the starting point for a bootstrap is 
C89 for the foreseeable future? (Not trying to be a nitpick pest, but actual 
data points are usually a good thing, and tcc supports only a few processors, 
so it would be nice to know which one and what platform, or is it some future 
thing.)

I like Larry's posting. Item 1 can also be done by text processing.

Or make a minimally functioning tcc C89 branch.

Or bootstrap it the Pascal P4 way.


(Offtopic, but tightly related to the full bootstrapping: if tcc would
also become relicensed to BSD-alike, this would not only make such
deep bootstrapping easier but also allow getting to C99 without
relying on GPL, which matters to some people and scenarios)

Thanks for your work on tcc,
Rune



--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia


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

Re: [Tinycc-devel] Using tinycc for full source bootstrapping

[KHMan]

On 9/27/2017 5:30 AM, u-j...@aetey.se wrote:

On Sun, Sep 24, 2017 at 07:40:32PM +0200, grischka wrote:

Also as source tcc is supposed to be C89, except maybe 'long long'
and maybe some minor things here or there which we could change
indeed if that is wanted (for example usage of compound initializers
in arm-gen.c)


[not a tinycc developer but using / depending on compiler bootstrapping]

I would find it awesome if tinycc would restrict its source to C89.


2017 - 1989 = 28.

Twenty-Eight Years. It would be kinda nice to move forward. Will 
we stick to C89 simply because of certain platforms that may never 
move forward? It's kinda like tying stones to one's legs. Or a 
lowest common denominator scenario.



Compilers written in C89 and understanding C99 hardly exist. This
makes it hard to do a proper bootstrap from the ground with minimal
dependency on existing binaries.


Could you give an example/examples where the starting point for a 
bootstrap is C89 for the foreseeable future? (Not trying to be a 
nitpick pest, but actual data points are usually a good thing, and 
tcc supports only a few processors, so it would be nice to know 
which one and what platform, or is it some future thing.)


I like Larry's posting. Item 1 can also be done by text processing.

Or make a minimally functioning tcc C89 branch.

Or bootstrap it the Pascal P4 way.


(Offtopic, but tightly related to the full bootstrapping: if tcc would
also become relicensed to BSD-alike, this would not only make such deep
bootstrapping easier but also allow getting to C99 without relying on GPL,
which matters to some people and scenarios)

Thanks for your work on tcc,
Rune


--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia


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

Re: [Tinycc-devel] Resources/questions for porting?

[KHMan]

On 9/26/2017 11:36 AM, Daniel Glöckner wrote:

Forgive me the brevity of my reply, but I should be asleep right now.

On Mon, Sep 25, 2017 at 09:16:12PM -0400, Charles Lohr wrote:

To do this, I need to port TCC to xtensa specifically lx6 with no floating
point.


It won't be easy to support floating point without floating point
registers. TinyCC is not prepared to keep floating point values in
integer registers. And you will need a soft float library like libgcc
that probably can't be built with TinyCC unless you also implement an
assembler.


Not a problem, the aforementioned ESP8266 is a hobbyist IoT 
favourite. Standard toolchain is gcc and newlib.


For a C app in firmware, most things can be done without floating 
point. Most old skool embedded coders will be doing fixed-point 
calculations. However, there are a few scripting platforms for 
ESP8266 (and more coming up), and platforms want to offer the most 
convenient scripting environment for possibly first-time coders 
who just want to get down to writing their app. So floats can be 
desirable or critical, depending on your target app demographic.


For NodeMCU on ESP8266, they should switch to Lua 5.3 and so avoid 
floats by using integers as much as possible while possibly 
retaining convenient float capability with a library such as 
Berkeley SoftFloat. For MicroPython, last I checked they didn't 
seem to be in a hurry to implement floats.


One advantage of tcc on ESP8266 would be that even the current tcc 
code quality will be much faster than Python or Lua scripts 
running on a VM.


References for convenience:

https://en.wikipedia.org/wiki/ESP8266
https://github.com/esp8266/esp8266-wiki/wiki/Toolchain
https://github.com/pfalcon/esp-open-sdk

https://docs.micropython.org/en/latest/esp8266/esp8266/general.html
https://en.wikipedia.org/wiki/MicroPython

https://en.wikipedia.org/wiki/NodeMCU
https://github.com/nodemcu/nodemcu-firmware

--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia


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

Re: [Tinycc-devel] Very sorry - newbie questions

[KHMan]

On 3/16/2017 12:33 AM, Tony Robinson wrote:



Date: Wed, 15 Mar 2017 12:45:08 +0800
From: KHMan <keinh...@gmail.com>
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Very sorry - newbie questions
Message-ID: <58c8c6d4.10...@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed


Just curious, I assume your project has to do with electronics
hardware in some form real or virtual, and related to embedded
hardware -- so I would like to ask one thing: Have you considered
SDCC? If so, would you like to comment on any TCC vs SDCC
considerations with regards to your project needs? (It is not my
intention to compare and declare winners, but only curious to
learn which one fits particular needs better in your case...)


My impression was that SDCC is the right choice if you wanted to
run on one of the supported processors, or had a lot of resources
behind you and wanted to provide really good support for a new
processor.

The manual says "8.3 Retargetting for other Processors: The issues
for retargetting the compiler are far too numerous to be covered
by this document."  It does point to a very brief wiki page,
http://sdcc.sourceforge.net/wiki/index.php/SDCC_internals_and_porting,
for which the main link is broken.   There's pointers to two
threads which don't see relevant.

So, in summary, I felt I had no chance with SDCC, it's too big and
porting isn't documented.


Yeah, I had a look at its source code way back in the past and 
didn't go further. I'm a lurker both here and there, getting code 
written gets in the way of hacking at a open source compiler...



That won't stop me using the floating point support though!


Any pros and cons versus Berkeley SoftFloat?

--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia


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

Re: [Tinycc-devel] Very sorry - newbie questions

[KHMan]

On 3/13/2017 4:47 PM, Tony Robinson wrote:

Doh.  Yup, it was a very newbie error, thanks to Ramsay Jones and
Michael Matz for pointing me at the git repo - that worked
flawlessly (I'd skim read the last 6 months of archives and misled
myself about release timings).

I do appreciate that there are very many hurdles to get tcc
running on a new bare metal target.  C itself mandates at least 16
bits for the int type, but I may find that tcc won't let me do
that.   Then there are libraries and system calls - I really don't
mind cheating and passing system calls and whatever libraries I
can't sensibly port to the Linux (Raspberry Pi) host - I'm not
going to write a whole OS in my 16 bit address space.   I know
I've got many years worth of challenges ahead, that's okay, I hope
I can spend many years on this project.


All the best on the project! I have this pile of old transistors 
and diodes and whenever I look at them my thoughts keep veering to 
the guy who did the 4004 in discrete device form...


Just curious, I assume your project has to do with electronics 
hardware in some form real or virtual, and related to embedded 
hardware -- so I would like to ask one thing: Have you considered 
SDCC? If so, would you like to comment on any TCC vs SDCC 
considerations with regards to your project needs? (It is not my 
intention to compare and declare winners, but only curious to 
learn which one fits particular needs better in your case...)



Thanks for you help and encouragement, I have fond memories of
decades of C programming and now I know where to start.


Happy hacking!
--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia


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

Re: [Tinycc-devel] Huge swings in cache performance

[KHMan]

On 1/10/2017 12:34 PM, David Mertens wrote:

64-byte alignment adds about 10% to the longer example program I
linked earlier (which actually prints the size of the allocated
code block). 10% isn't bad! For this reason, and because lots of
architectures use 64-byte cache lines, I suggest that we just use
64-byte alignment, independent of architecture.


A quick search gives this discussion on cache line sizes:
https://groups.google.com/forum/#!topic/comp.arch/9DcDSzs28Ow


Thoughts? Or, can anybody provide other memory consumption
benchmarks that paint a more complete picture?


I think memory consumption benchmarks is not a huge issue, if 
there is a pathological case with thousands of JIT'ed scripts, 
maybe a custom allocator for the scripts may save some memory.


I had always assumed that your program ran with data and memory 
separated enough not to mess with the L1 caches. So, is 64 byte 
align enough for your CPU? No effects beyond 64 bytes?


For BeagleBone Black, according to the AM335x Sitara Processors 
TRM, both L1 and L2 have cache lines of 16 words == 64 bytes, so 
that's another fella going with 64 bytes...



David

On Sun, Jan 8, 2017 at 7:40 AM, David Mertens wrote:

OK, done! And you were right, we only need to align on 64 bytes!

Follow-up question: since the alignment is only 64-bytes,
would it be sensible to have all architectures align to this,
including ARM?

David

On Sun, Jan 8, 2017 at 7:19 AM, David Mertens
>
wrote:

Thanks for the feedback, grischka.

On Sat, Jan 7, 2017 at 6:15 AM, grischka > wrote:

David Mertens wrote:

I just pushed a commit that sets up 512-byte
alignment for x86-64
architectures. It only uses 512 bytes for x86-64;
for all others it sticks
with the default of 16 bytes.


L1/L2 cache line size is 64 bytes on x86-like
processors, no matter
whether run in 32 or 64 bit mode.


Yes, theoretically we should not need to align on anything
more than 64 bytes. I chose 512 because I still got
slowdowns for smaller alignments, including 256. But you
mention...

However to make it work reliably the memory from
malloc needs to be
aligned as well, like so:

 offset = 0, mem = (addr_t)ptr;
+mem += -(int)mem & SECTION_ALIGNMENT;

and the possibly additional amount needs to be
requested in advance:

 if (0 == mem)
-return offset;
+return offset + SECTION_ALIGNMENT;


If I put this in place, then maybe the section alignment
can be lessened. I'll have to check. FWIW, I've been doing
this with my own TCC-calling code already and I've seen
performance benefits. I don't see how the math would work
to let me reduce SECTION_ALIGNMENT to 64 bytes, but I'll
experiment and see what happens.

All of this is a black box to me. From what I've read, I
don't think we'd need to worry about anything beyond 64
bytes, but I don't understand the underlying CPU behavior
well enough to predict. The numbers I actually use will be
based on real timing from testing on my machine or from
feedback from others.

I ran the tests on my BeagleBone Black with
the original alignment and saw no performance issues,


Obviously ARM don't automatically clear the
instruction cache which is
why we have the explicit __clear_cache() call for ARM
further down in
set_pages_executable().

I am not sure if this quite follows the project
practices. I define
SECTION_ALIGNMENT just prior to the function
tcc_relocate_ex. If anybody
can think of a better place to put it, to keep
useful things in one place,
please move it.


SECTION_ALIGNMENT seems too general as a name.
tccelf.c is full of
section_alignments of various kinds.  I'd suggest
something prefixed
with RUN_  to indicate that it's used only in that
specific place.


Can do! I may not have time today, but I should be able to
push a revised commit in the next couple of days.

David

--
  "Debugging is twice as hard as writing the code in the
first place.
   Therefore, if you write the code as cleverly as
possible, you are,
   by definition, not smart enough to debug it." -- Brian
Kernighan




--
  "Debugging is twice as hard as writing the code in the 

Re: [Tinycc-devel] Huge swings in cache performance

[KHMan]

On 1/6/2017 11:44 AM, David Mertens wrote:

Spot on, grischka!

Initial experiments indicate that changing the offset alignment
from 16 to 512 bytes (i.e. 15 to 511) solves this problem. I'll
try a few more experiments to be sure, though. I suspect that this
number should be tuned to the underlying architecture, but that's
not central to the discussion.


One thing that can trash I$ and D$ this way, a smart prefetcher... 
Any newish CPU could be susceptible.



David

On Thu, Jan 5, 2017 at 6:46 PM, grischka wrote:

You might try larger "section alignment" for -run:

in tccrun.c:208 instead of
 offset = (offset + 15) & ~15;
for example
 offset = (offset + 63) & ~63;

This would add more space between your "foo" data variable and
the instructions in memory

--- grischka


Harry van Haaren wrote:

On Thu, Jan 5, 2017 at 2:12 PM, avih > wrote:

I can reproduce x30 variations on Windows with tcc64
(built either using

gcc (mingw) or using tcc64 itself), but for me -DNOPS=2 or
5 or 9 are fast,
and the others (up to 9) are slow. I didn't check further.

I also removed the #include  since it's not
where tcc typically

is, and it's not required as far as I can tell, and also
removed the -B
thingy (the tcc binary is in the distribution dir on
windows and its
default -B location doesn't include anything other than tcc
files/libs/includes).

Same here, removed the stdio include and -B. flag, tcc
version 0.9.26
(x86-64 Linux), recent desktop CPU:
Results (below), even NOPS are bad, odd NOPS are good up
to 8, then it
becomes unpredictable.

Hope that helps, -Harry

PS: My first post to TCC list - awesome project - thanks
all! :)


time tcc -DNOPS=0 -run test.c
real0m1.015s

time tcc -DNOPS=1 -run test.c
real0m0.043s

time tcc -DNOPS=2 -run test.c
real0m1.215s

time tcc -DNOPS=3 -run test.c
real0m0.037s

time tcc -DNOPS=4 -run test.c
real0m1.008s

time tcc -DNOPS=5 -run test.c
real0m0.051s

time tcc -DNOPS=6 -run test.c
real0m1.010s

time tcc -DNOPS=7 -run test.c
real0m0.036s

time tcc -DNOPS=8 -run test.c
real0m1.014s

time tcc -DNOPS=9 -run test.c
real0m1.112s

time tcc -DNOPS=10 -run test.c
real0m0.041s

time tcc -DNOPS=11 -run test.c
real0m1.161s

time tcc -DNOPS=12 -run test.c
real0m0.039s

time tcc -DNOPS=13 -run test.c
real0m1.482s

time tcc -DNOPS=14 -run test.c
real0m1.009s

time tcc -DNOPS=15 -run test.c
real0m1.506s

time tcc -DNOPS=16 -run test.c
real0m1.005s




On Thursday, January 5, 2017 3:25 PM, David Mertens <

dcmertens.p...@gmail.com
> wrote:


Hello everyone,

I have now written a very simple C program which gives
highly erratic

timing behavior when run under tcc -run. I have added this
file to the
gist; look for cache-test-simple.c here:
https://gist.github.com/ run4flat/
fcbb6480275b1b9dcaa7a8d3a80846 38

The simple program does not attempt to produce a
shared object library,

and so should be runnable on any operating system that
supports tcc -run,
including Windows and Mac in addition to Linux. Here are
some sample
outputs on my machine:

$ time ./tcc -B. -DNOPS=0 -run cache-test-simple.c
real0m0.052s
$ time ./tcc -B. -DNOPS=1 -run cache-test-simple.c  ***
real0m1.413s
$ time ./tcc -B. -DNOPS=2 -run cache-test-simple.c
real0m0.069s
$ time ./tcc -B. -DNOPS=3 -run cache-test-simple.c
real0m0.076s
$ time ./tcc -B. -DNOPS=4 -run cache-test-simple.c  ***
real0m1.158s

The starred results are over an order of magnitude
slower than the

unstarred results.

1) Do others see this on other operating systems with
64-bit Intel

processors?

2) Do others see this on any operating system with
64-bit AMD processors?
3) Do others see this on any operating system with any
other architecture?

Thanks!
David

On Thu, Jan 5, 2017 at 12:59 AM, David Mertens
>

wrote:

Update: I *can* get this 

Re: [Tinycc-devel] Huge swings in cache performance

[KHMan]

On 12/21/2016 12:02 PM, David Mertens wrote:

I forgot to mention: the function in question is a simple random
number generator. It only contains 32-bit integer math operations,
and does not contain any loops. For this benchmark, the looping
occurs at the Perl level, so alignment optimizations for looping
would not be important here. (This lets me compare many different
Perl-to-C function invocation approaches to assess their speed.)


Curiouser and curiouser. The Icache misses really bothers me. Is 
it just L1 caches that blew up or are the L2 caches naughty as 
well? Would love to hear more of your progress on this list...



On Tue, Dec 20, 2016 at 10:44 PM, David Mertens wrote:

Discussion about alignment and execution speed for the Haskell
compiler: https://ghc.haskell.org/trac/ghc/ticket/8279
<https://ghc.haskell.org/trac/ghc/ticket/8279>

This discussion mentions why things should be aligned, and
gives some multi-byte no-ops that can be used for padding for
aligned loops.

http://stackoverflow.com/questions/18113995/performance-optimisations-of-x86-64-assembly-alignment-and-branch-prediction

<http://stackoverflow.com/questions/18113995/performance-optimisations-of-x86-64-assembly-alignment-and-branch-prediction>

I came across a similar issue a few weeks ago, but I was able
to "fix" it by allocating more memory than I needed and then
relocating to an address within that allocation that was
aligned to the start of a page. This seemed to fix the problem
back then, but this new flavor of alignment woes is impervious
to such a trick.

David

On Tue, Dec 20, 2016 at 10:29 PM, KHMan <keinh...@gmail.com
<mailto:keinh...@gmail.com>> wrote:

On 12/20/2016 10:17 PM, David Mertens wrote:

Hello Kein-Hong,

I'm not convinced this is entirely an unpredictable
hardware
issue. The reason is that I can easily create similar
functionality with gcc (the usual Perl XS module, the
normal means
for writing a C-based extension) and it does not show
these kinds
of cache swings. I think there is something gcc does while
producing its machine code that makes it less
susceptible to cache
misses. (Well, there are lots of things it does, I'm
sure.) I'm
hoping there's one or two simple things that gcc does
which tcc
misses and could implement.

Was the behavior observed with Lua noted when working
with JIT?


I couldn't find the old posting but it was along the lines
of benchmark variability due to memory layout, see
"Mytkowicz memory layout". IIRC, the discussion was about
a small benchmark Lua script running the interpreter, in
one posting, changing an environment variable changed the
program's total running time significantly, IIRC it was in
the 20-50% range. The timings were done casually and
nobody did detailed follow-up research.

... which of course are the same executables and is
different from your case. Long day and all. But tcc is not
much of an optimizing compiler, if the change caused
register spilling in an inner loop it would hammer memory
access and account for at least some of the effects...


    On Tue, Dec 20, 2016 at 9:05 AM, KHMan wrote:

 On 12/20/2016 9:16 PM, David Mertens wrote:

 Hello everyone,

 Reminder/Background: C::Blocks is my Perl
wrapper around
 my fork
 of tcc with extended symbol table support.

 I've begun writing benchmarks to seriously
test how C::Blocks
 compares with other JIT and JIT-ish options
for Perl. I've
 noticed
 a couple of situations in which slight
modifications to
 the code
 cause a huge drop in performance. One
benchmark went from
 370ms to
 5,000ms (i.e. 5 sec).

 The change to the code was so slight that I
immediately
 suspected
 cache misses as the culprit. Running with
linux's "perf"
 command
 gave proof of that (hopefully this format
properly with
 fixed-width characters):

 FastSlow  Significant
 time (ms)  3705022**
 instructions  3.5B3.5B
 branches  640M650M
 branch-miss   687k  

Re: [Tinycc-devel] Huge swings in cache performance

[KHMan]

On 12/21/2016 11:44 AM, David Mertens wrote:

Discussion about alignment and execution speed for the Haskell
compiler: https://ghc.haskell.org/trac/ghc/ticket/8279
<https://ghc.haskell.org/trac/ghc/ticket/8279>

This discussion mentions why things should be aligned, and gives
some multi-byte no-ops that can be used for padding for aligned
loops.
http://stackoverflow.com/questions/18113995/performance-optimisations-of-x86-64-assembly-alignment-and-branch-prediction


Unfortunately much of these stuff involve compiler optimization, 
that'll be plenty of work to do for tcc to make it work well. In a 
perfect world, we would detect CPU model/family/features and JIT 
it perfectly to suit, heh heh :-)


Since x86 parallel decoders can decode only a certain mix of 
instructions, looking at Agner Fog's doc, if tcc chooses many 
instructions that uses multi-uOps, then for those instructions a 
decoder may process only one instruction per clock, instead of up 
to 4. Easy to gum up the works. But adding an optimization 
framework for instruction selection and organization for optimal 
decoding is a big thingy...



I came across a similar issue a few weeks ago, but I was able to
"fix" it by allocating more memory than I needed and then
relocating to an address within that allocation that was aligned
to the start of a page. This seemed to fix the problem back then,
but this new flavor of alignment woes is impervious to such a trick.


Amazing how far we've come compared to Michael Abrash's black 
books, there are so many interacting modules in a modern x86 part.


Luckily I rarely need top performance and thus stopped worrying 
about these things long ago :-) It's hard for most regular coders 
to chase down such performance issues, it's a never-ending struggle...



On Tue, Dec 20, 2016 at 10:29 PM, KHMan
[snipped]
On 12/20/2016 10:17 PM, David Mertens wrote:
[snipped]


--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia


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

Re: [Tinycc-devel] Huge swings in cache performance

[KHMan]

On 12/20/2016 10:17 PM, David Mertens wrote:

Hello Kein-Hong,

I'm not convinced this is entirely an unpredictable hardware
issue. The reason is that I can easily create similar
functionality with gcc (the usual Perl XS module, the normal means
for writing a C-based extension) and it does not show these kinds
of cache swings. I think there is something gcc does while
producing its machine code that makes it less susceptible to cache
misses. (Well, there are lots of things it does, I'm sure.) I'm
hoping there's one or two simple things that gcc does which tcc
misses and could implement.

Was the behavior observed with Lua noted when working with JIT?


I couldn't find the old posting but it was along the lines of 
benchmark variability due to memory layout, see "Mytkowicz memory 
layout". IIRC, the discussion was about a small benchmark Lua 
script running the interpreter, in one posting, changing an 
environment variable changed the program's total running time 
significantly, IIRC it was in the 20-50% range. The timings were 
done casually and nobody did detailed follow-up research.


... which of course are the same executables and is different from 
your case. Long day and all. But tcc is not much of an optimizing 
compiler, if the change caused register spilling in an inner loop 
it would hammer memory access and account for at least some of the 
effects...



On Tue, Dec 20, 2016 at 9:05 AM, KHMan wrote:

On 12/20/2016 9:16 PM, David Mertens wrote:

Hello everyone,

Reminder/Background: C::Blocks is my Perl wrapper around
my fork
of tcc with extended symbol table support.

I've begun writing benchmarks to seriously test how C::Blocks
compares with other JIT and JIT-ish options for Perl. I've
noticed
a couple of situations in which slight modifications to
the code
cause a huge drop in performance. One benchmark went from
370ms to
5,000ms (i.e. 5 sec).

The change to the code was so slight that I immediately
suspected
cache misses as the culprit. Running with linux's "perf"
command
gave proof of that (hopefully this format properly with
fixed-width characters):

FastSlow  Significant
time (ms)  3705022**
instructions  3.5B3.5B
branches  640M650M
branch-miss   687k671k
dcache-miss   974k 71M**
icache-miss   3.2M 83M**

By dcache-miss I refer to what perf calls "L1 dcache load
miss",
and by icache-miss I refer to what perf calls "L1 icache
load miss".

I'm a bit confused on what would cause this sort of persistent
cache miss behavior. In particular, I've tried working
with highly
distinct strategies for managing executable memory, including
ensuring page alignment (wrong: it should be line-width
alignment
of 64 bytes). This fixed a similar issue previously
observed, but
didn't seem to improve the situation here. I used malloc
instead
of Perl's built-in memory allocator. I created a pool for
executable memory so that multiple chunks of executable
code would
all be written to the same page in memory. EVEN THIS did
not fix
this issue, which really surprised me since I would have
thought
adjacent memory would hash to different caches.

I believe that what I've found is an issue with tcc, but I
haven't
golfed it down to a simple libtcc-consuming example. I can do
that, but wanted to see if anybody could think of an obvious
cause, and fix, without going to such lengths. If not, I
will see
if I can write a small reproducible example.


This kind of behaviour was discussed on the Lua list not long
ago. IIRC, for example changing environment variables changed
the way a program is loaded, and the timing changed. Probably
cache behaviour. It's like, what can we really benchmark anymore?

When modern GHz parts have cache misses and need to access
main memory, they cause such train wrecks that everybody seems
to be moving or have already moved to neural network-based
(perceptron *cough*) branch prediction.

So well, how do we scientifically or meaningfully benchmark
these days, that is the question... (especially for folks in
academic needing to justify benchmark results...)



--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia


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

Re: [Tinycc-devel] Huge swings in cache performance

[KHMan]

On 12/20/2016 9:16 PM, David Mertens wrote:

Hello everyone,

Reminder/Background: C::Blocks is my Perl wrapper around my fork
of tcc with extended symbol table support.

I've begun writing benchmarks to seriously test how C::Blocks
compares with other JIT and JIT-ish options for Perl. I've noticed
a couple of situations in which slight modifications to the code
cause a huge drop in performance. One benchmark went from 370ms to
5,000ms (i.e. 5 sec).

The change to the code was so slight that I immediately suspected
cache misses as the culprit. Running with linux's "perf" command
gave proof of that (hopefully this format properly with
fixed-width characters):

   FastSlow  Significant
time (ms)  3705022**
instructions  3.5B3.5B
branches  640M650M
branch-miss   687k671k
dcache-miss   974k 71M**
icache-miss   3.2M 83M**

By dcache-miss I refer to what perf calls "L1 dcache load miss",
and by icache-miss I refer to what perf calls "L1 icache load miss".

I'm a bit confused on what would cause this sort of persistent
cache miss behavior. In particular, I've tried working with highly
distinct strategies for managing executable memory, including
ensuring page alignment (wrong: it should be line-width alignment
of 64 bytes). This fixed a similar issue previously observed, but
didn't seem to improve the situation here. I used malloc instead
of Perl's built-in memory allocator. I created a pool for
executable memory so that multiple chunks of executable code would
all be written to the same page in memory. EVEN THIS did not fix
this issue, which really surprised me since I would have thought
adjacent memory would hash to different caches.

I believe that what I've found is an issue with tcc, but I haven't
golfed it down to a simple libtcc-consuming example. I can do
that, but wanted to see if anybody could think of an obvious
cause, and fix, without going to such lengths. If not, I will see
if I can write a small reproducible example.


This kind of behaviour was discussed on the Lua list not long ago. 
IIRC, for example changing environment variables changed the way a 
program is loaded, and the timing changed. Probably cache 
behaviour. It's like, what can we really benchmark anymore?


When modern GHz parts have cache misses and need to access main 
memory, they cause such train wrecks that everybody seems to be 
moving or have already moved to neural network-based (perceptron 
*cough*) branch prediction.


So well, how do we scientifically or meaningfully benchmark these 
days, that is the question... (especially for folks in academic 
needing to justify benchmark results...)


--
Cheers,
Kein-Hong Man (esq.)
Selangor, Malaysia


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

Re: [Tinycc-devel] vectorize the curent hash implementation

[KHMan]

On 4/23/2016 4:26 PM, Vladimir Vissoultchev wrote:

[snip snip snip]
(Note: SSE calc loop oversteps input string so file buffer has to
overallocated by 8 bytes in `tcc_open_bf`)

Unfortunately there was no noticable improvement, which leads me to beleave
that hash calculation is not the main culprit for the performance of
`next_nomacro1`


IIRC there are fast LZ compressors that are trying to use vector 
registers to speed up hashing. But those have nice and small inner 
loops.


But compilers branch all over the place, there are no nice inner 
loops to let L1 caches go hot-rodding, there are many data 
dependencies which limit a CPU's ability to schedule multiple ops. 
Branch and cache mispredictions are like train crashes these days.


Perhaps someone can test the limits on one of those academic CPU 
simulators that has an 'oracle' cache setting. How much speed can 
we further squeeze? I'm not optimistic there is a lot of 
performance left to squeeze...



-Original Message-
From: Tinycc-devel On Behalf Of Sergey Korshunoff
Sent: Saturday, April 23, 2016 10:38 AM
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] vectorize the curent hash implementation

Hi!

IMO, the way to go w/ performance improvement is to vectorize the curent

hash implementation. Instead of computing the hash one character at a time,
take next 4 characters, process these in parallel and compute 4 hashes

How to implement this?
There is some hash optimization for the tcc compiled by gcc.
https://github.com/seyko2/tinycc/commit/b89f0d63af4f494a83c91fb0360d7d37c0f6
f9a3


--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] License is too restrictive for real-world use.

[KHMan]

On 3/2/2016 7:01 PM, John B wrote:

@ Stephan,
[snip]
Despite the implications that I am a bad person for asking, I
think the discussion is healthy for the project.  Because bsd
license I believe would be 100x healthier for the project.  People
would absolutely contribute back, but in a de-identified way.
  I Absolutely believe this.


No, in 13 years I've been hanging around here there is just a 
severe lack of resources. If the market had real interest and 
resources for a BSD/MIT licensed tinycc thing, then someone would 
be done it a long time ago. It would have been much easier to 
start from scratch as BSD/MIT rather than try to switch this license.


But guess what? No resources. Nobody with gobs of time to expend. 
So, not going to happen, unless someone gets up and engage in a 
few man-years of work to make it happen. LuaJIT is a one-person 
project too. Sure LLVM has plenty of resources, but tinycc is in a 
different niche.


--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] License is too restrictive for real-world use.

[KHMan]

On 3/2/2016 6:08 PM, John B wrote:

[snip]
Maybe being upfront with this community was a mistake but I knew that risk and 
10/10 would take it again.  I just wish you would see that at least I am not 
lying to anyone.  Again, you ask for kickbacks fine but don't do it in the same 
email as trying to take a moral high ground with me.


I would like to say that I greatly respect Daniel's position, much 
more than yours.


As for your project, I wish you a sincere good luck. You know, 
there are great MIT-licensed JIT compilers around. Happy hacking!



[snip snip]
Subject: Re: [Tinycc-devel] License is too restrictive for real-world use.

On Wed, Mar 02, 2016 at 08:38:45AM +, John B wrote:

I love playing around with toys and trying to make them better. It beats
sudoku.  But I am not going to surreptitiously steal the software but on
the cooperative flip side of that coin, I don't want to release my code,
either.


After reading your side of the story, I have the feeling that keeping my
parts of TinyCC as LGPL was the right choice.

TinyCC is a small project with very few active developers. If your product
uses TinyCC, you should feel the responsibility of committing improvements
you made back the main project. (If on the other hand your product consists
mainly of a modified version of TinyCC, you can try to convince us by
offering a share of your earnings. ;)

Best regards,

   Daniel


--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] More questions about DLLs made with TCC

[KHMan]

On 1/12/2016 4:15 PM, Ben Hutchinson wrote:

[snip snip snip] Can somebody please fix that bug?


Are you aware of the amount of resources available to most small 
Open Source projects?


Strutting about like a peacock every other day is highly unlikely 
to move anything forward. It's like asking a tiny village Why In 
The World Is The Great Pyramid Not Done Yet. Sure, you're 
contributing 'reports' of a sort, but is this the best way?


The most valuable currency is usually working patches. Sure, if 
there is bugzilla then you can fill it with 1000 tickets, but 
instead of doing that, why not stop and Think. What of the more 
fundamental issues that need to be addressed for instance? Then I 
hope you will choose to put your time and effort into actions that 
are more useful.


--
Cheers,
KHMan
KL, MY


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

Re: [Tinycc-devel] TCC's preprocessor for other use?

[KHMan]

On 1/8/2015 1:05 AM, Kevin Ingwersen (Ingwie Phoenix) wrote:

I am working on a project that involves AngelScript, which is a C++ like 
scripting language. But I wanted to add a preprocessor to it. Is it possible to 
embed TCC’s preprocessor into another app? I have never seen TCC running an 
external process for preprocessing files, which is why I believe that it must 
be inside it entirely.


This may be a better option:
http://mcpp.sourceforge.net/

--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] 回复: jiang, please indent properly!

[KHMan]

On 5/14/2014 12:52 PM, Nicolas Limare wrote:

On Wed, May 14, 2014 at 10:32:36AM +0800, jiang wrote:

I did not mean it, I will immediately change overnight


If your text editor doesn't offer this option, you can use the
`expand` program.
- http://linux.die.net/man/1/expand


Another way is to find an editor with per-directory-tree 
customization. Once set up, I am reasonably sure each project 
source tree is edited according to its norms. I use SciTE for 
that, I'm sure there are other editors that have the feature.



You can even do that automatically with a pre-commit hook.
- 
http://www.seriousramblifications.com/2013/05/coding-standards-artistic-style-and-git.html


--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] TCC, king of small exe... hey wait...

[KHMan]

On 9/21/2013 12:49 AM, Yann Collet wrote:

[snip]
Initially, my intention was to use TCC in order to produce small
exe. After all, this is one of the advertised properties of TCC.
(see
http://en.wikipedia.org/wiki/Tiny_C_Compiler#Compiled_program_performance)


Don't believe Wikipedia. The part, produces very small 
executables is rubbish. Use your own judgment and ask yourself, 
how much size optimizations can a _tiny_ C compiler have.



[snip]
So now for the questions :
- Is the analysis proposed above correct ? Or need to be elaborated ?
- Is it even an objective for TCC to generate small-size exe ?


How many hundred hours of manpower can you contribute to code the 
optimizations? :-)


--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] Question on Stack Overflow about weird rounding with tcc

[KHMan]

On 8/28/2013 5:06 AM, David Mertens wrote:

Hey everyone -

I found this question from somebody use tcc v0.9.24:

http://stackoverflow.com/questions/18417788/pow-cast-to-integer-unexpected-result

The basic question is, Why does tcc's compilation output (100,
99) whereas other compilers output (100, 100)?

|#include  stdio.h
#include  math.h

int  main(void)
{
 printf(%d,,  (int)  pow(10,  2));
 printf(%d,  (int)  pow(10,  2));
 return  0;
}|


More useful would be the exact double output from pow(), or dump 
the raw bytes too. I'm guessing it's almost 100. Anything that use 
native instructions might experience non-exact results because of 
the way pow() is calculated. Even old library calls might produce 
that.


Most C libs guarantee exact results where the number do not 
overflow the available digits of precision by testing and 
special-casing for integers.


--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] Do we want a BSD license for tinycc?

[KHMan]

On 5/1/2013 5:58 PM, Daniel Glöckner wrote:

On Tue, Apr 30, 2013 at 09:14:58PM +0200, Marc Andre Tanner wrote:

The fear of proprietary forks seems
unfounded because there is already a mature BSD licensed C compiler
(clang) available for people to base their work on.


Let's see..
$ size /opt/llvm/bin/clang
text   data bss dec hex filename
389997781193992   54640 40248410266245a /opt/llvm/bin/clang

I think TinyCC might be preferred by some people who just need a
small scripting engine.


I would vote for a BSD licensed tinycc (remembering that talk is 
easy, manpower supply is hard). Given a show of hands, I think BSD 
would come out on top. After all, it's not a state-of-the-art 
thingy with a huge potential market; CINT and Ch for example have 
not gained much traction beyond niche areas. Much more advanced 
compiled/JITed scripting engines like LuaJIT are already BSD licensed.


LGPL holdouts can be removed in the BSD version and be relegated 
to legacy status. Perhaps big contributions can be evaluated early 
to assess deletions. The main problem is the issue of doing a 
thorough audit of code ownership. Of course, I'll leave that to 
those supplying the manpower...


--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] Do we want a BSD license for tinycc?

[KHMan]

On 5/1/2013 7:10 PM, Armin Steinhoff wrote:

Daniel Glöckner wrote:

On Tue, Apr 30, 2013 at 09:14:58PM +0200, Marc Andre Tanner wrote:

The fear of proprietary forks seems
unfounded because there is already a mature BSD licensed C compiler
(clang) available for people to base their work on.

Let's see..
$ size /opt/llvm/bin/clang
text   data bss dec hex filename
389997781193992   54640 40248410266245a /opt/llvm/bin/clang

I think TinyCC might be preferred by some people who just need a
small scripting engine.


TinyCC ist the only compiler which provides JIT compiling for ARM


http://luajit.org/luajit.html
http://luajit.org/performance_arm.html

--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] Do we want a BSD license for tinycc?

[KHMan]

On 5/1/2013 9:51 AM, Rob Landley wrote:

On 04/30/2013 11:53:31 AM, Daniel Glöckner wrote:

On Tue, Apr 30, 2013 at 05:43:03PM +0200, Thomas Preud'homme wrote:
 As I already said privately, I'm fine with BSD-2-clause.

Does that mean you prefer it over the LGPL?


http://www.youtube.com/watch?v=SGmtP5Lg_t0#t=15m10s


What about you, grischka? Which one do you prefer?


Why on earth would that matter?

I identified a dozen people I have to talk to just to get a clean
version of the code in _my_ fork. You guys have been doing a mob
branch for years, with random drive-by commits from people you
don't even know, who have zero ongoing relationship with the project.

What makes you think you _can_ relicense your version?


I agree with Rob. Too many large and small contribs to be casually 
discussing about relicensing...


--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] TCC and smart linking

[KHMan]

On 10/11/2012 6:14 PM, Oleg N. Cher wrote:

Thank you for words of wisdom that Milutin Jovanović said.

2 Jared Maddox: I do not acts as domineering screamer.
I just unpleasantly surprised that the thing that should be in the
compiler is perceived by someone as an optional extra feature. And
the reducing size of a compiler and wish to have fast compilation
are called as obstacles and reasons not to implement smart
linking. But all that I suggest is to increase *average*
compilation speed more.
And do you want to be offended by me or assist to give themselves
and others a good compiler? [snip snip snip]


The crux of the matter is this: tcc is a resource-starved project. 
This is common with lots of small, niche projects.


The problem with giving ideas is that no one will implement them. 
The only thing that will move the project forward is actual code 
or patches.


Even if people are excited about a proposal, getting it done is 
another big problem. I've seen a lot of coders wanting to do some 
feature, but end up abandoned and forgotten. Heck, I've done that 
lots of times myself.


So you need to be cognizant of the project's limitations and the 
community's limitations, because we too have tons of ideas, and 
too little time to implement them.


Long story short, if you can code, you have the power. The only 
opinion that really matter is the fellow who has the commit 
permissions for tcc. It can always be forked if opinions differ, 
no big deal.


--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia

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

Re: [Tinycc-devel] Re: Simple Registry Key Create and Write. Multi Errors in Tiny C

[KHMan]

On 8/10/2010 10:10 PM, ED GROSSHEIM wrote:

[snip]
When I added the registry functions to my CreateProcess file, the
.exe size went from 10 kb to 30 kb. I want my .exe starter to be
small.


I think that if your program is coded well, and you use the 
correct compiler options, the most practical things to do is to be 
happy with the result.


So for me, if I have a DLL that compiles to 44KB from 2500 lines 
of heavily commented code, I would say that it's small enough.


Unless you have extremely specific and unavoidable needs to have 
the binary to be really small, then putting so much effort into 
making things small is usually a waste of time. Take it from me, I 
had to unlearn stuff like that because in the past, we had to 
stuff whole programs into 3.5KB of memory.


--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia

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

Re: [Tinycc-devel] Where is Intel ABI(Application Binary Interface) document?

[KHMan]

Supervisor Root wrote:
 Recently I am writing a C compiler, I need know some knowledge about 
 Intel X86 ABI for Windows and Linux. I searched the internet by Google, 
 but I haven't found the document. I found a document which described 
 System V ABI, but It is different with Windows and Linux platform.
  
 Who can tell me that where is Intel X86 ABI(Application Binary 
 Interface) document for windows and linux? Please give me a URL address.

Best place to start:
http://www.agner.org/optimize/

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia



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

[Tinycc-devel] Re: Drop mercurialtcc [TinyCC on Mercurial]

[KHMan]

Detlef Riekenberg wrote:
On Di, 2007-11-13 at 14:04 +0800, KHMan wrote: 

Hi all,

mercurialtcc has been accepted on ShareSource. The URL is:

http://sharesource.org/project/mercurialtcc/


In the old CVS-Only live of tcc, the inofficial mercurial tree
was created.
We have the git tree now, so I like to drop the old outdated code.

Any objections?


Nope, zap away ;-)

--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia



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

Re: [Tinycc-devel] C Exception Handling: Any takers?

[KHMan]

Ivo wrote:

On Thursday 03 September 2009 16:21, Mikael Lyngvig wrote:

I can see that almost 40 people have read my little paper on extending
C with exception handling, but I have received no emails regarding the
issue.


One of those 40 was me. In principle, I like your implementation, but I 
don't think it belongs in a C compiler. I don't get the whole fuzz about 
exceptions anyway. Nevertheless, if you want to find people that might be 
interrested in your ideas, I think the LLVM development mailinglist would 
be your best choice. Especially if you could make it work for C++ 
execptions, too. IIRC, there has been a thread there about different 
trade-offs for exception handling implementations recently.


I've read it too. To Mikael:

I think it will have to be the original author's responsibility to 
create a usable implementation, since it appears the paper has not 
excited anyone. Wrapping a single statement in a try{} block is a 
trivial example; you need to show non-trivial examples, plus 
things like throwing across call boundaries, etc. Also, C++ 
handles object destruction etc., and also, there are downsides to 
over-using the exception paradigm. It's a hard sell.


Since you have not heard from anyone, realistically I think you 
will need to do your own implementation. Often, active Open Source 
developers have too many ideas, too little time. For most FLOSS 
projects, developer resources is a very scarce commodity.


Even if tcc adopts an implementation, it will only be a curio, 
because tcc not being a mainstream production compiler cannot 
drive adoption of cute stuff. Hence, this is a really uphill 
thing... good luck anyway.


--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] Re: TCC:cannot find -lxyz.dll

[KHMan]

lostgallifreyan wrote:

Jon A. Lambert jlamb...@oh.rr.com wrote:
(09/04/2009 09:57)


I never use the desktop as a file storage area


Ok, I'll bite.  Storage? If that counts the temporay storage of moderately 
sized files in a working session or two then yes, I use it for storage. I kind 
of thought that's what desktops were for. :)


Guys, this thread isn't really productive anymore. Granted, a lot 
of us do specific things that works perfectly well for ourselves. 
For example, I compile a custom-patched text editor that I use, 
which to others may well be rightfully construed as a stupid waste 
of effort. So there isn't going to be a resolution to this 
discussion since each of us will stand firm -- it's going round 
and round and round, so why not let us instead stick to the proper 
topic of this list, which is the development of tcc.


At the end of the day, AFAIK the decision to pick patches for the 
main trunk still lies with grischka. So why don't lostgallifreyan 
push a suitable patch to the mob branch, or post it on this list. 
It may go in, or it may not go in, but at least those who need 
such a patch can presumably find it while searching. It must also 
be said that many projects with responsible developers often say 
no as much as they say yes, so let us now get a handle on this 
matter like mature-minded developers.


--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] Newcomer to TCC (and C) with a couple ofquestions..

[KHMan]

Kalle Olavi Niemitalo wrote:

lostgallifreyan lostgallifre...@gmail.com writes:


You cite from MSDN... I take it this is because TCC defaults to
using MSVCRT? (Or, I read tonight, Kernel32.dll if the program
entry point was written to avoid using MSVCRT).


The Windows GDI functions are in USER32 and GDI32, not MSVCRT.
I cite from MSDN because Microsoft has designed the GDI functions
(the first ones perhaps in cooperation with IBM, for OS/2?) and
maintains them as part of Windows and gets to decide how they
work.


Apart from the links to Win32 help files that grischka has 
mentioned, a alternative that is a little more up-to-date is the 
PlatformSDK_Svr2003R2_rtm ISO (just do a Google search). It's 
nicely packaged (self-contained, unlike a lot of other similar 
downloads) and small (~400MB) compared to the latest SDKs (1GB). 
It installs MSDN-style Win32 API documentation that uses a 
CHM-like browser, good enough if you are not aiming for the latest 
APIs (it has pre-Win2K info up to WinXP info, but no Vista) and 
does not want to use MSVC++ Express.



[snip snip]

And that means I'm not sure how I should write any GDI
oriented code if I want it to compile on Linux. I'd thought the
same might apply to both.


Ah, you mentioned GDI resources in your original post, so I
assumed you were intending the program to run on Windows only.
If it needs to run on Linux too, then you could perhaps use
Winelib http://www.winehq.org/site/winelib, which I believe
implements the Windows GDI functions on Linux.  Alternatively,
use some cross-platform graphics API such as GDK
http://library.gnome.org/devel/gdk/ or SDL
http://www.libsdl.org/ or even OpenGL; at least these three
should be usable from C without C++, and thus presumably with
TCC.  However, if you are already familiar with GDI and have a
lot of code that uses it, then switching to a different API may
require too much work.


Given the lack of knowledge of the OP in these nitty-gritty 
details, I would like to suggest that the OP use a standard C/C++ 
compiler like MinGW on Win32. Say as a beginner, you just want to 
write an application, so do stick to a compiler that is already 
well-tested like MinGW (on Win32), or say you want to write an app 
really quickly, you can use the wxLua that was mentioned earlier 
(which uses wxWidgets, a good commercial-quality and mature 
cross-platform widget set, and you develop in C++).


But of course, if the OP has unlimited amounts of time at his 
disposal, by all means try TCC and help with the development and 
use of TCC. I am a little worried that the OP might be trying to 
bite off more than he can chew -- if he is new to C, then I don't 
think he should be using TCC at all, it's not a production-quality 
compiler. Stick to the ubiquitous gcc.


--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: Vs: [Tinycc-devel] opengl lib for tinyCC? (Kenneth Forsb?ck)

[KHMan]

云帆江 wrote:

hi
 i am just a newbie on this,and i found many code sample written in cpp 
not c
and the opengl lib for mingw seems dont work well on my system,can u 
give an simple example and all files tarball


tcc is only C, not C++. If your concern is more on developing 
apps, perhaps it's wise to stick to a more commonly used compiler.


OpenGL on MinGW works fine for me. You should stick to MinGW, it 
works fine for a lot of people. Are you sure the code samples are 
written for MinGW or in a platform neutral way? You can ask for 
help on the MinGW list, or if you are using OpenGL with SDL, you 
can ask on the SDL list.



-
Date: Thu, 18 Dec 2008 11:34:57 +0200 (EET)
From: Kenneth Forsb?ck
Subject: Vs: [Tinycc-devel] opengl lib for tinyCC?
[snip]

I have found that the official OpenGL headers or the ones from MinGW 
work quite well. You could also just tiny_impdef the OpenGL libraries 
you are using and just let the linker do most of the work, although that 
would make debugging your code more difficult (compiler not able to 
check the routine definitions).


--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] register and volatile

[KHMan]

Jerry wrote:

Hi All,
As far as I know, a variable with register storage class will probably 
be optimized to be
having no RAM storage but only staying in a CPU register. A volatile 
variable will only 
be read by RAM access. But what about a variable declared as volatile 
with register 
storage class?


register is advisory, it is up to the compiler to ultimately 
decide what to choose. volatile is mandatory, otherwise your 
program will break or work funny. You probably should read Derek 
Jones' The New C Standard (http://www.knosof.co.uk/cbook/cbook.html)


--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] [PATCH 5/5] Fix gv for long longs

[KHMan]

Laurens Simonis wrote:
You could also use bzr, which can also easily import cvs repo's, and even still 
be a server for read-only cvs access, for those who still want that.


Check out the CVS section on

http://bazaar-vcs.org/BzrMigration


We do have a sorta 'parallel' repository on Mercurial (hg) on 
ShareSource. Detlef is in charge, IIRC. But we haven't heard much 
of the hg repo on this list. I see mostly grischka running the 
show. Using bzr or git won't solve anything. We'd still need 
someone who is 'actively' in charge of the proceedings.


Our priority should not be revision control systems. Our problem 
is that we need two or three active devs can act on patches and 
discussions quickly, to provide that semblance of movement. If we 
have that, RCS issues will seem much less pressing. I think those 
interested and able to review patches should lobby to get cvs 
credentials.


We need what any good novel has -- movement, or action to the 
effect that it creates the perception that the show is trundling 
along at a brisk clip.


--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] [PATCH 5/5] Fix gv for long longs

[KHMan]

Rob Landley wrote:

On Saturday 06 September 2008 05:41:21 KHMan wrote:

Laurens Simonis wrote:

You could also use bzr, which can also easily import cvs repo's, and even
still be a server for read-only cvs access, for those who still want
that.

Check out the CVS section on

http://bazaar-vcs.org/BzrMigration


My preference for hg is a personal preference, I also use git for projects 
that use that, and I even use subversion for a few projects that I'm not 
active enough on to bother creating a mercurial mirror.

[snip]


Of course I agree with all of your (Rob's) arguments, and I'm sure 
most others as well. Don't need to keep repeating arguments I 
already agree with. I just think this project should deal with 
manpower first, and I'm RCS-neutral. I'm awfully, dreadfully sorry 
that I accidentally mentioned CVS in giving an opinion.


Okay then, you know, we're going around in circles. :-) This is 
exactly like a past discussion that ended up with me setting up 
the hg repository. So I did try to get this tcc onto a modern 
distributed RCS, and then managed to get Detlef to take over, but 
no commits in the past 7 months or so. Anyone care to continue 
that? So that's one data point. It says we need muscle.


No muscle, no results. Need'um reliable muscle first, else 
everything is stuck. Even the scenario where you (Rob) kindly send 
patches over under LGPLv2 requires muscle plus a distributed RCS. 
I was just trying (very carefully, knowing you are around, but 
obviously not carefully enough) to point out to the list that 
without reliable muscle, nothing is going to move.


So to keep my message simple -- what we need is action, and I 
think those who can take action gets to decide. Forget I ever 
mentioned CVS. We're beggars here, the thingy is mostly in deep 
freeze, and in my very humble, personal opinion, I think I would 
accept a bowl of plain rice instead of holding out and starve in 
hope of a gourmet meal. I also think opinions like mine are very 
cheap, thus I fervently hope for someone to step up to the plate.


--
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

[Tinycc-devel] A couple of TCC-related links - bindings to scripting langs

[KHMan]

Hi all,

Someone mentioned Odyce on the Lua list today, it uses TCC/libtcc
for embedding C (dynamic compilation) into Tcl. So, here are the
URLs for two bindings of TCC -- these might possibly be useful if
put on the website -- Googling tcc binding currently does not
return very useful results...

(1) Odyce - Tcl binding
http://www.evolane.com/software/odyce/index.html
(2) Luatcc - Lua binding
http://luatcc.luaforge.net/

HTH,
-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia



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

[Tinycc-devel] Odyce and TCC, any LGPL problem?

[KHMan]

Hi all,

I mentioned Odyce, a Tcl binding in an earlier post. The URL is:
http://www.evolane.com/software/odyce/index.html

Unfortunately, perhaps I shouldn't have mentioned Odyce. Any
Evolane people on this list? There is only a single executable,
TCC *appears* to be embedded inside that executable (not sure if
it's static linkage), and there is no LGPL notice anywhere to be
found in the Win32 or Linux packages.

I do not think this is common (or fair or honourable) practice,
and I can't seem to find a link to source code. The packages have
EULAs with just the Tcl license, plus a catch-all line: The
Package may contain software covered by other licenses: I doubt
the catch-all is appropriate legal text given that TCC is LGPL.

At a glance, ETcl looks like freeware, not F/LOSS software, and
their business model is consultancy. Is this (TCC embedded inside
a single executable, no license text) acceptable usage of TCC?
Since I was the one who mentioned Odyce, it's my fault, so I had
to point it out. I will leave it to the developers to take action,
if deemed necessary.

Sorry if anyone thinks this is noise... HTH,
-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia



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

Re: [Tinycc-devel] Using TinyCC with GPL

[KHMan]

Rob Landley wrote:
 On Friday 06 June 2008 15:34:41 Ivo wrote:
 If you use Rob Landley's fork, your application must be GPL as Rob switched
 to the GPL for all of tinycc.
 
 Thanks for the FUD, but if you'd bothered to read the README:
 
 License:
 ---

 Tinycc is distributed under GPL version 2.  (This is a specific version of
 the GPL, included in the file LICENSE in this tarball.  It may not be
 distributed under later versions.)

 The license on tinycc does not apply to output files produced by tinycc
 (which are under whatever licenses the corresponding source files were
 under), nor does it affect the header files in the include directory (look
 up Scenes a Faire and the merger doctrine).
 
 By your logic, #including standard headers out of /usr/include would make 
 your 
 program GPL.  For example, the glibc /usr/include/errno.h includes the glibc 
 bits/errno.h, which includes linux/errno.h which is a file taken from the 
 Linux kernel and licensed under GPLv2 (not LGPL).  So any code that #includes 
 the standard header errno.h is sucking in source code from the Linux kernel 
 when it compiles.
 
 If it worked that way then every program ever compiled for Linux would be GPL 
 version 2.  There would be no binaries available under GPLv3, or the artistic 
 license, or mozilla license, or BSD, or any proprietary license.

Ivo is right. Please read Yann Renard's original post again. My
reading of the OP says that he is embedding a scripting language,
not using it with #!. This is not mere aggregation, plus he is
providing tcc as an integral and essential part of the
application, hence Ivo is correct, otherwise FSF wouldn't have a
need to write the LGPL license to cater to applications that
aren't GPL-compatible.

Your (Rob's) position is obviously correct for cases where a
scripting language is used like the way Perl is traditionally
used, but if Ivo and I are correct about the OP's intention of
embedding tcc (where the application is running scripts internally
as one entity and tcc is in no way used as a system library), then
the application would have to be GPL-compatible.

As for header files, I believe it would depend on whether the
scripting language is to be considered a part of the system
libraries or an integral part of the application. In this case,
the intention is for tcc to be an integral element, so the
application has to be GPL-compatible.

Please correct me if I am wrong.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] tcc-0.9.24 release soon

[KHMan]

grischka wrote:
 From: KHMan:
 
 Binary releases calls for certain expectations from their uses.
 
 That is true, also it calls for certain users per se. But why 
 exclude such users?  Programmers writing programs only for 
 programmers has some boring aspect too, IMO.

That was a typo, I meant 'users'.

 On Tue, Mar 4, 2008 at 5:37 AM, grischka wrote:

 Should we make a release now?
 Sure, why not? If you want to be conservative, perhaps mark or
 announce or document it as an unstable release. 
 
 Hm, what would be the benefit of that?

You decide. I was just a commit monkey, and it's just a cheap
opinion. I was implying more of a 'minor release' concept, since
there have been many commits after a long while in wilderness, but
of course these are incredibly subjective concepts.

Some feedback is better than no feedback, right? Very little
traffic and hardly any replies to new postings these days. I've
tried to stay out of the way, and the moment I try one post, this
Rob guy jumps all over it. That's why I try to lurk these days; I
didn't want to tempt Rob. Rob should put me in his killfile, then
he wouldn't get distracted. *grin*

As for Rob's reply, thanks. My words are all just mere opinions,
and I respect diverse opinions. He shouldn't need to use so many
words to put his point across, one paragraph should be enough. Of
course Rob has a point, I don't disagree, but it doesn't change
the fact that *this* tcc severely lack resources. My concept of
'resources' also obviously includes 'interest'. *shrug*

Remember, please don't mistake me for an authoritative voice! I am
just a list member who was a commit monkey for a while. I don't
make policy for anyone here.

Win32 binaries is for grischka or Detlef to decide, my feedback
should very obviously not be construed as policy. Rob is a super
developer and is going great guns, sure, and pushing out binary
releases can be mostly automated, sure, but here we can't get
discussions on new patches and queries going, so why provide
binaries when we have failed to discuss or deal with feedback that
benefits tcc, such as RFC patches or user feedback? Unless
grischka or Detlef have dealt with those feedback privately... but
normally one discusses these things on-list, so please correct me
if I am wrong.

So there.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] tcc-0.9.24 release soon

[KHMan]

Hanzac Chen wrote:
 Win32 binaries with Win32 Api definitely needed.
 The libtcc.a and libtcc.h for dynamically compilation.

Speaking as a list member, I'll all for more services for users,
but let's be realistic: I don't think this community has the
resources to maintain binary releases. We have postings with
hardly any replies. We are severely resource-constrained.

Note that nobody has responded to grischka's _actual_ topic of
discussion after over 48 hours. Can this community maintain and
support binary releases? Binary releases calls for certain
expectations from their uses.

IMHO, those who wish to utilize tcc actively should be challenged
to jump over this barrier of getting the sources compiled. If
say P encounters a bug, at least P can help report or fix the bug
and refresh the sources via CVS or hg and then recompile.

Can someone can put forward a strong case for releasing regular
Win32 binaries?

 On Tue, Mar 4, 2008 at 5:37 AM, grischka wrote:
 
 Should we make a release now?

Sure, why not? If you want to be conservative, perhaps mark or
announce or document it as an unstable release. Some movement is
always good. :-)

 Any suggestions what to still include with it?

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia



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

Re: [Tinycc-devel] TCC built using NOSTDLIB crashes on linux

[KHMan]

Hi all,

Rob Landley wrote:
 On Friday 01 February 2008 22:23:54 KHMan wrote:
 [snip]
 Anyway, off to do other things...

Given Rob's style, I'm not going to respond in any big way except
to say that perhaps my slight aversion to spoon-feeding is
apparently not in style. Well, I wish to say that Rob is free to
say and speculate on whatever he wants if he thinks that it
validates his position. Finally I'll just say thanks to him for
looking into Mike's problem, if for some reason Mike doesn't want
to post further. Heh. I apologize to the list for inadvertently
mentioning Rob's name in my posting.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia



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

Re: [Tinycc-devel] etiquette

[KHMan]

Laurens Simonis wrote:
 Is there some mailing list etiquette about not mentioning another's name?
 
 [snip]
 The above is ment to be as objective as possible. Personally, I think it's a 
 shame that this hostility exists, and think it's counterproductive. He comes 
 back to help, and _still_ isn't apperciated. I, for one, _do_ apperciate his 
 efforts.

To reiterate my position to avoid misunderstanding, I am rather
neutral about Rob and I try to be tolerant. I have defended his
actions on this list before. But when I see time and effort and
resources being wasted, I guess I am firm, but I don't think I am
evil. So, that statement in my last post is not a kick to anybody,
it is a kick at myself. It implies a bit of list-specific cultural
knowledge. It's too bad the English language carries to much
ambiguity.

The above is not helpful; grishka clarified a few things, I
thanked Rob in my postings. By the above, it appears that people
might see aggression where there is none. Asserting one's point of
view while allowing for a plurality of viewpoints is not attacking
someone. If anyone read aggression, then they are reading too much
into it -- and at some point, any statement might be construed as
aggressive -- making a blowup a 100% certainty. This posting
itself -- my saying a lot in response to the above -- might also
be construed as an unhappy me whacking you. Heh. If people
choose to think so, there's nothing one can do to smooth things.
For example, if X with a virtual avatar or emphatic model of Y
'sees' the situation as Y whacking X, then Y can't do anything to
smooth things in a non-face-to-face situation, because the
emphatic model is in X's head.

Be warned that this can happen to anyone else on the list.
Everyone should be less sensitive, but I guess this is a basic and
apparently intractable problem with online discussions. It is an
interesting scientific or psychological phenomenon, and I don't
think I have a solution for it.

 Also, I think that since this is the only place to ask questions about tcc, 
 this 
 is the perfect spot for Mike's question. Where else should he go but here? Of 
 course, there's no guarantee that someone will answer, but just sometimes, 
 someone might just have had the exact same problem, so why not ask? If you 
 don't 
 want to answer, don't :)

In retrospect, that's somewhat true. In a low traffic list like
this where stuff don't get a response routinely, someone coming
here for this kind of help is not likely to get a response.
Sometimes, that leads to hostility when newbies get frustrated,
but Mike has been a perfect gentlemen, bless you. My other
examples were not meant to imply anything except that problem
descriptions should be backed by a certain amount of useful
investigative effort. Also, the question was not really about tcc
and the problem description was somewhat misleading unless one
actually tested it.

I guess we should end this here. At least I will. I will try to
avoid promoting self-sufficiency and anti-spoon-feeding in the
future. :-) ;-)

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] TCC built using NOSTDLIB crashes on linux

[KHMan]

Rob Landley wrote:
 On Thursday 31 January 2008 21:23:49 KHMan wrote:
 Mike wrote:
 I was trying to compile TCC using the -nostdlib option.

 (Here's my command (which works))
 bash$ gcc -nostdlib -o tcc tcc.c /usr/lib/crt1.o /usr/lib/crti.o -ldl
 -lc -lgcc
 bash$

 (Here's my result (which is a crash))
 bash$ ./tcc qwert
 Segmentation fault (core dumped)
 bash$

 [snip] You can also try Rob Landley's
 fork and see if the same issue appears.
 
 My build system's totally different, but I'm happy to help him with his 
 issue.  
 (I don't post much on a list I was asked to leave, but as long as my name's 
 come up anyway...)

Thanks Rob for chipping in. My suggestion was probably a little
too speculative, sorry, it was not a helpful suggestion anyway.
Sorry to have distracted you, perhaps you should just delete
off-on-a-wild-blue-yonder stuff like this next time, unless it is
a valid bug, etc. :-)

 Did you try building a hello world program with that command line, to see 
 if 
 _that_ segfaults?

I tried that on Ubuntu 6.10. Just ./tcc alone core dumps; if
he's asking about why ./tcc qwert failed, I'd question whether
he has done any homework himself. So if Mike wants to play with
non-standard link options, he'd better be prepared to conduct some
investigation of his own. Perhaps he needs to write a test case
for *gcc* that works with the -nostdlib thingy and exercises the
bunch of symbols tcc needs, before attempting the same trick on
the whole kaboodle.

My first posting was mainly out of concern; enthusiasts should not
be routinely asking for the very limited resources of tcc
developers or the list to chase down these things -- it is not a
real good use of their time. On the Mingw list, there was two
cases in two weeks where somebody treated the list like tech
support, and in a demanding and somewhat belligerent manner. Us
old-timers gawk mutely and wonder in awe at such audacious
jaw-dropping behaviour. :-)

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia



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

Re: [Tinycc-devel] TCC built using NOSTDLIB crashes on linux

[KHMan]

Mike wrote:
 I was trying to compile TCC using the -nostdlib option.
 
 (Here's my command (which works))
 bash$ gcc -nostdlib -o tcc tcc.c /usr/lib/crt1.o /usr/lib/crti.o -ldl
 -lc -lgcc
 bash$
 
 (Here's my result (which is a crash))
 bash$ ./tcc qwert
 Segmentation fault (core dumped)
 bash$
 
 Do you get this same error?  What's the cause?
 (My system specs are Ubuntu 7.10, gcc 4.1.3)

Time out. I think you should adjust your expectations a little
bit. We are just a community list, and tcc has a severe lack of
developer resources. I don't think the list should be in the
business of providing tech support. People who dare to jump in and
try out tcc must at least have a fair bit of self-sufficiency.

Perhaps you can help us by diagnosing the problem (you can build
it, so would you like to try some debugging?) and give us a useful
lead so that one of the active developers on this list can issue a
patch with the minimum of fuss. You can also try Rob Landley's
fork and see if the same issue appears.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] Worm virus

[KHMan]

Gary Dumer wrote:
 AVG antivirus is detecting a WORM virus in all the EXEs on my WindowsXP.
 I'm using a recent version of TCC.

Ummm... what does it have to do with tcc?

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia



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

Re: [Tinycc-devel] tiny_impdef.c raw file format on CVS is Windows format?

[KHMan]

Philippe Ribet wrote:
 Timovj Lahde wrote:
 
 Philippe Ribet wrote:
   
 May be a policy could be defined? For example, all files could be in
 unix style in the repository. It's up to the windows tools to convert
 them (if needed) in windows style when downloaded. In fact, many
 windows
 tools will be able to understand unix style, which means conversion or
 no conversion will be no problem.
 
 My personal view: Like it or not, other CRLF files may enter the
 archive sometime in the future. If not for tcc, then for other
 projects where contributors work on different platforms. Setting
 policies is a waste of time; this project has no resources, none
 whatsoever, so let's not waste time on bureaucracy.
   
 CVSNT.EXE co -kb option for binary mode keeps file unmodified.

IMHO, things 'should' be okay without -kb too, because if line
endings are recognized properly, you should still be able to work
with the ensuing CRLF text files. But it isn't, so it's a bug, and
tcc should not be in the business of documenting workarounds for
such basic tools. Anyway, this is getting OT.

 Of course, that's fine with me. So, instead of putting guidlines to cvs
 commiters,  CVSNT.EXE co -kb solution may be add in some README file
 or readme for cvs users.

I won't be patching the documentation on the Mercurial repository.
This is an elementary and general issue that has to do with CVS;
tcc should not maintain FAQ items dealing with CVS, let alone one
specific to CVSNT. Developers who aspire to use tcc should be able
to handle this issue with no problems whatsoever, or at least be
able to troubleshoot and solve the problem on their own.

HTH,
-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] tiny_impdef.c raw file format on CVS is Windows format?

[KHMan]

Please consider avoiding top-posting for discussions, it's easier
to follow things going from top down. Thanks.

Feng Nauh wrote:
 In hex mode, tiny_impdef.c has line feed as 0x0D 0x0D 0x0A.
 mixed by CR  CRLF.

Okay, I've got a similar report from Timovj Lahde.

Can you describe the version of cvs and platform you are using? If
you can troubleshoot the issue, better still.

Checkout was fine on Cygwin's CVS. I use the following CVS options
for checkout: -z6 -P -kb

Deleted the file and did checkout again. No problem with
tiny_impdef.c. Looked at it with a hex editor, seems fine. Got a
copy from Savannah through the web interface, looked at it with a
hex editor, seems fine.

If it's a CVSNT problem, then I can't really help troubleshoot, no
experience with it.

I'm by no means a CVS guru, just a braindead commit monkey, so if
anyone out there can help, please speak up.

 On Dec 6, 2007 10:04 AM, KHMan [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:
 
 Hanzac Chen wrote:
  Just using the tcc itself. The message is:
  C:/tinycc/tiny_impdef.c:14: stray '\' in program
 
 Just sync'ed with CVS and ran it on MinGW/Msys. Both gcc and tcc
 compiles tiny_impdef.c without any trouble. You'd have to provide
 more detail of what you've done if you want your problem
 diagnosed. HTH.
 
  On Dec 6, 2007 12:02 AM, KHMan wrote:
 
  tiny_impdef.c in the CVS does indeed has CRLF line endings. What
  is the error message when compiling tiny_impdef.c? What compiler
  are you using?

HTH,
-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] tiny_impdef.c raw file format on CVS is Windows format?

[KHMan]

Hanzac Chen wrote:
 Hi,
 
 On Dec 6, 2007 4:32 PM, KHMan wrote:
 [snip]
 
 If it's a CVSNT problem, then I can't really help troubleshoot, no
 experience with it.
 
 I think it's CVSNT problem, on Windows, the default setting is using DOS
 format. I believe the CVS client knows it's talking with the server on
 Unix and converts all the text files to DOS format. But if the text file
 on the server is DOS format, it will also do the conversion.

I guess line ending conversion needs to be 'smart', otherwise --
disaster. Thanks for the report.

 [snip]

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] tiny_impdef.c raw file format on CVS is Windows format?

[KHMan]

Hanzac Chen wrote:
 I check out the sources of tinycc from Savannah CVS but found the
 tiny_impdef.c can't be compiled because of the file format problem. As
 I'm working on Windows, and the CVS program automatically converts all
 the text files from unix format to windows format. But I guess the
 tiny_impdef.c format on the server is Windows format then the file
 format after converted is corrupted.

tiny_impdef.c in the CVS does indeed has CRLF line endings. What
is the error message when compiling tiny_impdef.c? What compiler
are you using?

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] tcc's TODO list: bug with defines - already solved?

[KHMan]

Joshua Phillips wrote:
 from TODO:
   - bug with defines:
   #define spin_lock(lock) do { } while (0)
   #define wq_spin_lock spin_lock
   #define TEST() wq_spin_lock(a)
 it appears that this is already solved.
 Defining these and invoking TEST() behaves as gcc with tcc -E, and it appears 
 to compile properly. tcc also compiles it properly at revision 338. Am I 
 missing something?

I'll try to confirm this behaviour and put it together with the
comment patch and commit this over the weekend. If anyone has
documentation or comment updates, please post them to the list and
I'll compile the bits and pieces.

 (sorry if I'm causing excess mailing list traffic)

Not at all, the more traffic on development the better. :-) A big
change from the long periods of silence in the past...

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] .hgtags in .hgignore?

[KHMan]

Joshua Phillips wrote:
 I've just noticed that .hgtags is in the .hgignore list - this doesn't seem 
 right!

I've no idea whether it's right or wrong; didn't touch it since
initial importing. Either I'll look at the hg docs in a day or
two, or someone who's familiar with hg on this list can comment.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] [BUNDLE] Eliminate many bogus warnings produced during compilation of tcc by gcc

[KHMan]

Joshua Phillips wrote:
 Patch by David Wheeler; I've committed it to the incoming branch.
 (unpack using hg unbundle ...)

Thanks, I plan to get the patches into the 'incoming' branch this
weekend. But luckily for us, we can probably make 'incoming' a
separate repository later, and have separate repositories for
active developers.

This just in from Tim Groeneveld of ShareSource:

* ShareSource will soon have the possibility to create
  additional repositories within a project, which means
  instead of people committing to the 'main' repository,
  they push to a repo containing his own local changes.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] .hgtags in .hgignore?

[KHMan]

Dave Dodge wrote:
 On Wed, Nov 28, 2007 at 09:12:37AM +0800, KHMan wrote:
 Joshua Phillips wrote:
 I've just noticed that .hgtags is in the .hgignore list -
 this doesn't seem right!
 I've no idea whether it's right or wrong;
 
 I don't think it's a problem.  [snip]
 
 Note that despite being in .hgignore, the .hgtags file _is_ under
 revision control, as can be seen by doing hg log .hgtags.  Assuming
 you use hg tag to add tags, they'll get committed immediately and
 the fact that hg status ignores the file is a non-issue.

Roger that, thanks,
-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] [BUNDLE] Eliminate many bogus warnings produced during compilation of tcc by gcc

[KHMan]

Joshua Phillips wrote:
 Patch by David Wheeler; I've committed it to the incoming branch.
 (unpack using hg unbundle ...)

Committed to branch incoming, thanks.

I'll do some testing and merge them into mainline this weekend,
then add Marc's preprocessor-newline.patch. Marc's soname.patch is
under RFC status so I'll leave it to the list to discuss the thingy.

Standard message about the hg repository:
=
tcc's unofficial public developer's repository is at:
  http://hg.sharesource.org/mercurialtcc/
Synchronization with official CVS is ongoing.
Maintainers/Owner wanted for Mercurial repository, please
ping the list if interested. ShareSource plans to allow multiple
repositories per project soon, so participation most welcome.
Incoming patches in need of independent testing: 2
(committed under branch incoming)

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] Breaking tcc into manageable chunks

[KHMan]

Joshua Phillips wrote:
 Oughtn't tcc be broken into multiple source files?

I tried studying the sources over the weekend, and it looks like a
lot of functionality is mashed together, due to its tiny
heritage. So I think breaking up tcc.c would be a non-trivial
task. Perhaps worth a shot, though.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

[Tinycc-devel] Trivial spelling patch

[KHMan]

Hi all,

This trivial patch fixes some spelling mistakes. If anyone has a
documentation or comment patch, I can put such minor patches
together and commit them in one go. I won't commit this for now,
just posting to notify the list first.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia

diff -r 218d28dbcf0b arm-gen.c
--- a/arm-gen.c Fri Nov 16 12:16:14 2007 +0800
+++ b/arm-gen.c Tue Nov 27 15:25:09 2007 +0800
@@ -1380,7 +1380,7 @@ static int is_fconst()
 }
 
 /* generate a floating point operation 'v = t1 op t2' instruction. The
-   two operands are guaranted to have the same floating point type */
+   two operands are guaranteed to have the same floating point type */
 void gen_opf(int op)
 {
   unsigned long x;
diff -r 218d28dbcf0b c67-gen.c
--- a/c67-gen.c Fri Nov 16 12:16:14 2007 +0800
+++ b/c67-gen.c Tue Nov 27 15:25:09 2007 +0800
@@ -235,7 +235,7 @@ void gsym(int t)
 }
 
 // these are regs that tcc doesn't really know about, 
-// but asign them unique values so the mapping routines
+// but assign them unique values so the mapping routines
 // can distinquish them
 
 #define C67_A0 105
@@ -2250,7 +2250,7 @@ void gen_opi(int op)
r = vtop[-1].r;
fr = vtop[0].r;
vtop--;
-   C67_MPYI(fr, r);// 32 bit bultiply  fr,r,fr
+   C67_MPYI(fr, r);// 32 bit multiply  fr,r,fr
C67_NOP(8); // NOP 8 for worst case
break;
 case TOK_SHL:
@@ -2307,7 +2307,7 @@ void gen_opi(int op)
 }
 
 /* generate a floating point operation 'v = t1 op t2' instruction. The
-   two operands are guaranted to have the same floating point type */
+   two operands are guaranteed to have the same floating point type */
 /* XXX: need to use ST1 too */
 void gen_opf(int op)
 {
diff -r 218d28dbcf0b i386/i386-asm.c
--- a/i386/i386-asm.c   Fri Nov 16 12:16:14 2007 +0800
+++ b/i386/i386-asm.c   Tue Nov 27 15:25:09 2007 +0800
@@ -25,7 +25,7 @@ typedef struct ASMInstr {
 uint16_t opcode;
 uint16_t instr_type;
 #define OPC_JMP   0x01  /* jmp operand */
-#define OPC_B 0x02  /* only used zith OPC_WL */
+#define OPC_B 0x02  /* only used with OPC_WL */
 #define OPC_WL0x04  /* accepts w, l or no suffix */
 #define OPC_BWL   (OPC_B | OPC_WL) /* accepts b, w, l or no suffix */
 #define OPC_REG   0x08 /* register is added to opcode */
@@ -385,7 +385,7 @@ static inline void asm_modrm(int reg, Op
 gen_expr32(op-e);
 } else {
 sib_reg1 = op-reg;
-/* fist compute displacement encoding */
+/* first compute displacement encoding */
 if (sib_reg1 == -1) {
 sib_reg1 = 5;
 mod = 0x00;
diff -r 218d28dbcf0b i386/i386-gen.c
--- a/i386/i386-gen.c   Fri Nov 16 12:16:14 2007 +0800
+++ b/i386/i386-gen.c   Tue Nov 27 15:25:09 2007 +0800
@@ -164,7 +164,7 @@ static void gen_addr32(int r, Sym *sym, 
 gen_le32(c);
 }
 
-/* generate a modrm reference. 'op_reg' contains the addtionnal 3
+/* generate a modrm reference. 'op_reg' contains the additional 3
opcode bits */
 static void gen_modrm(int op_reg, int r, Sym *sym, int c)
 {
@@ -750,7 +750,7 @@ void gen_opi(int op)
 }
 
 /* generate a floating point operation 'v = t1 op t2' instruction. The
-   two operands are guaranted to have the same floating point type */
+   two operands are guaranteed to have the same floating point type */
 /* XXX: need to use ST1 too */
 void gen_opf(int op)
 {
diff -r 218d28dbcf0b il-gen.c
--- a/il-gen.c  Fri Nov 16 12:16:14 2007 +0800
+++ b/il-gen.c  Tue Nov 27 15:25:09 2007 +0800
@@ -600,7 +600,7 @@ void gen_opi(int op)
 }
 
 /* generate a floating point operation 'v = t1 op t2' instruction. The
-   two operands are guaranted to have the same floating point type */
+   two operands are guaranteed to have the same floating point type */
 void gen_opf(int op)
 {
 /* same as integer */
diff -r 218d28dbcf0b libtcc.h
--- a/libtcc.h  Fri Nov 16 12:16:14 2007 +0800
+++ b/libtcc.h  Tue Nov 27 15:25:09 2007 +0800
@@ -55,7 +55,7 @@ int tcc_compile_string(TCCState *s, cons
 /* linking commands */
 
 /* set output type. MUST BE CALLED before any compilation */
-#define TCC_OUTPUT_MEMORY   0 /* output will be ran in memory (no
+#define TCC_OUTPUT_MEMORY   0 /* output will be run in memory (no
  output file) (default) */
 #define TCC_OUTPUT_EXE  1 /* executable file */
 #define TCC_OUTPUT_DLL  2 /* dynamic library */
diff -r 218d28dbcf0b tcc.h
--- a/tcc.h Fri Nov 16 12:16:14 2007 +0800
+++ b/tcc.h Tue Nov 27 15:25:09 2007 +0800
@@ -352,7 +352,7 @@ struct TCCState {
 Section *plt;
 unsigned long *got_offsets;
 int nb_got_offsets;
-/* give the correspondance from symtab indexes to dynsym indexes */
+/* give the correspondence from symtab indexes to dynsym indexes */
 int *symtab_to_dynsym;
 
 /* temporary dynamic symbol sections (for dll loading) */
@@ -528,7 +528,7 @@ struct TCCState {
 #define TOK_SHL   0x01 /* shift left */
 

Re: [Tinycc-devel] Using resource files with tcc. How do I do that?

[KHMan]

Knut Flock wrote:
 Could you, or someone else, review these commands and tell me where I'm
 wrong?
 [code]
 tcc -c -W1,--oformat,coff test.c
 rc testRC.rc
 link /out:test.exe test.o testRC.res
 [/code]
 link returns:
 test.o : fatal error LNK1136: invalid or corrupt file
  
 The tcc document page claims (if I understand right) that the tcc
 command switch -W1,--oformat,coff will create a format only targeting a
 specific CPU (TMS320C67xx) So it will not help me target a x86 based
 computer (even if coff is the default MS format)?

On a project with very limited resources like tcc, you should be
using the source first... and most developers are expected to be
able to handle significant problem-solving tasks on their own...

Please check with the sources, then ping the list. If checking the
sources is a problem, perhaps you shouldn't be using tcc at all...

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] Re: Attempt to create a host on ShareSource failed

[KHMan]

Marc Andre Tanner wrote:
 Piotr Skamruk wrote:
 * KHMan, ([EMAIL PROTECTED]) napisał:
 [...]
 He's moving to GPL, and it's now tinycc.
 AIR he can't do that with only Fabricios permition.
 to do that he should have permission from anyone who ever add some patch
 to tcc, accepted in mainline, from he started.
 
 No LGPL $3 says:
 [snip]
 
 but of course IANAL. I asked him off list for the reason behind the
 license change, he basically doesn't want that his code could end up
 under GPLv3. I personally don't care which license is used but i think
 whoever wrote most of the code should decide the license and even if
 it's legal to change the license it's not particularly nice (see the
 whole BSD/Linux Wireless driver ath5k issue).

I concur. The freedoms spelled out in most, or all, FLOSS
licenses, bears the risk of forking, and forking can be good or it
can be bad. Personally, I would respect the intentions of the main
owner(s).

In any case, let us focus our energies instead on the LGPL tcc.
Please try it and contribute what you can. We are in need of
testers and maintainers. I for one hope interested developers are
kept focused on a LGPL hg/cvs tree rather than on a GPL tree.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] [PATCH] Check for duplicate definitions of variables

[KHMan]

Joshua Phillips wrote:
 oops, slight mistake, sorry. Here is replacement patch.
 --
 I was going to send this as a high-tech Mercurial bundle, but then I realized 
 I'd transplanted the parent, so it was a bit difficult. Here's a low-tech 
 patch file instead.
 
 Check for duplicate definitions of variables

Since there is a lack of person(s) to review patches at the
moment, I propose to start a branch in the Mercurial repository
named incoming for convenient testing, and push this patch into
the branch. If no one objects to this, I will try branching and
then update the server in about 2 days.

Standard message about the hg repository:
=
tcc's unofficial public developer's repository is now at:
  http://hg.sharesource.org/mercurialtcc/
Synchronization with official CVS is ongoing.
Maintainers/Owner wanted for Mercurial repository, please
ping the list if interested. Participation most welcome.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] [PATCH] ignore #ident preprocessor directive

[KHMan]

Joshua Phillips wrote:
 Maybe.

Awesome, if you can review patches, even better. The main thing
now is to rebuild some momentum, demonstrate signs of life, then I
think tcc will start moving forward again.

 On Friday 16 November 2007 04:33:33 KHMan wrote:
 Maintainers/Owner wanted for Mercurial repository, please
 ping the list if interested.

Thanks,
-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] tinycc Changelog bcheck.c il-gen.c libtcc1.c tcc.c

[KHMan]

grischka wrote:
 From: KHMan:
 I updated from CVS, make tcc works on msys/mingw and Ubuntu
 6.10. make libtcc borks on my Ubuntu 6.10, dunno why.
 
 Um, error message? 

Ha ha, it was a dumb mistake I made trying to bypass texi2html,
which I had not installed. Missed the .a at the end of
libtcc... brain fade. :-) Anyway, I've installed texi2html and a
simple make now builds everything on vanilla Ubuntu 6.10.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia



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

[Tinycc-devel] Query: anyone with a patch for Cygwin?

[KHMan]

Hi all,

Does anyone have a patch to make tcc configure and compile on
Cygwin? I can't seem to compile tcc cleanly on Cygwin. It would be
a nice thing for those poor us stuck in between *nix and win32. I
was thinking of tweaking the msys/mingw configuration to do that.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia



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

Re: [Tinycc-devel] tinycc Changelog bcheck.c il-gen.c libtcc1.c tcc.c

[KHMan]

grischka wrote:
 CVSROOT:  /sources/tinycc
 Module name:  tinycc
 Changes by:   grischka grischka 07/11/14 17:34:31
 
 Modified files:
   .  : Changelog bcheck.c il-gen.c libtcc1.c tcc.c 
 
 Log message:
   Import some changesets from Rob Landley's fork (part 1)
 [snip]

I updated from CVS, make tcc works on msys/mingw and Ubuntu
6.10. make libtcc borks on my Ubuntu 6.10, dunno why.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] [PATCH] Check for duplicate definitions of variables

[KHMan]

Joshua Phillips wrote:
 oops, slight mistake, sorry. Here is replacement patch.
 --
 I was going to send this as a high-tech Mercurial bundle, but then I realized 
 I'd transplanted the parent, so it was a bit difficult. Here's a low-tech 
 patch file instead.
 
 Check for duplicate definitions of variables
 
 Added global Sym *local_compound which is a pointer into the local
 symbol stack to mark the start of the current compound statement.
 
 The following are valid:
 int a, a; /* in a global context */
 int a; { int a; } /* in a function */
 
 The following now throw errors:
 int a, a; /* in a function */
 void foo(int a, int a);
 enum { a, a };
 union { int a; int a; };
 struct { int a; struct { int a; }; };

This is a pending patch I found in my tcc e-mail folder. There may
be more, if so, please ping the list.

I'll need an aye from someone before committing.

As always, maintainers/developers for tcc's Mercurial repository
wanted.

Thanks,
-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia



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

Re: [Tinycc-devel] [PATCH] ignore #ident preprocessor directive

[KHMan]

Sanghyeon Seo wrote:
 2007/11/14, Marc Andre Tanner [EMAIL PROTECTED]:
 The following patch makes tcc ignore the the #ident preprocessor
 command.
 
 FYI, GCC documentation on this strange directive.
 http://gcc.gnu.org/onlinedocs/cpp/Other-Directives.html

Thanks, I'll add that to the changeset message.

-- 
Cheers,
khman
KL, MY


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

[Tinycc-devel] Re: Attempt to create a host on ShareSource failed

[KHMan]

KHMan wrote:
 [snip]
 Information used in the registration attempt:
 
 shortname: mercurialtcc
 fullname: TinyCC on Mercurial
 license: GNU Lesser General Public License (GLGPL) (v2.1)

I have submitted the above to ShareSource. Sorry about the
threading problem replying to my own posting; the mailing list
settings is correct on the FSF server but I am not receiving my
own posts.

Anyway, I actually tried tcc-unofficial but they filter out all
punctuation. So I figure mercurialtcc will suffice. I guess
ShareSource should actually use red for errors...

If it gets approved, I will look into importing Seo's bundle, then
completely transfer ownership to others. At least two persons, for
redundancy. At least in this way we will have a public hg host.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia



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

Re: [Tinycc-devel] Re: Attempt to create a host on ShareSource failed

[KHMan]

Sanghyeon Seo wrote:
 2007/11/13, KHMan [EMAIL PROTECTED]:
 Also, we cannot pull patches from him anymore, unless he offers
 them to 'official'/'semi-official' tcc. It would have been nice to
 have him still contributing to a LGPL tcc, but I guess not.
 
 Yes. My bundle is the last revision before switching to GPL.
 http://sparcs.kaist.ac.kr/~tinuviel/download/tinycc.bundle

Thanks, I concur, I took a close look at the short changelog as
well upon seeing the GPL changes.

Have to wait for the ShareSource people now. I'll report any
updates to the list. If anyone knows of another hg public host,
please let the list know.

Thanks,
-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

[Tinycc-devel] mercurialtcc [TinyCC on Mercurial] accepted on ShareSource

[KHMan]

Hi all,

mercurialtcc has been accepted on ShareSource. The URL is:

http://sharesource.org/project/mercurialtcc/

The project, to me, is strictly an unofficial development tree
meant to allow for the convenience of modern distributed version
control, and it will serve to supply patches to further the
development of the official tcc tree.

I'm looking around, not really sure how to import the bundle in
properly. I'm still reading hgbook, so any volunteers to set up
the repository using Seo's bundle? We need at least two people as
maintainers, for redundancy. Please ping the list or send me an
e-mail, and I'll add you in the developer's list. If anyone wants
to be head developer, just let me know, and I'll transfer
ownership in double-quick time.

I suggest having tinycc as a subdirectory within mercurialtcc as a
big container, which can also accommodate any side projects that
developers on the list may have.

Thanks,
-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia



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

Re: [Tinycc-devel] mercurialtcc [TinyCC on Mercurial] accepted on ShareSource

[KHMan]

Sanghyeon Seo wrote:
 2007/11/13, KHMan [EMAIL PROTECTED]:
 I'm looking around, not really sure how to import the bundle in
 properly.
 
 You simply push to the URL. If you have your local repository in
 tinycc directory,
 
 cd tinycc
 hg push http://hg.sharesource.org/mercurialtcc
 
 And you're done. Mercurial will ask your username and password interactively.

Thanks, I have uploaded your bundle successfully. Cloned
successfully as well. Please test and see if it's Okay Go. For
non-hg users, I used:

hg clone http://hg.sharesource.org/mercurialtcc

zip and bz2 bundles are also available for non-hg users.

Maintainers welcome, otherwise I will just act as a pull monkey or
a braindead commit monkey for now. I don't know enough to do QC or
judge patches. Please post patches to this list only and let
members of the list decide whether the patches are any good. Even
Rob, if he wants to participate, is very much welcome.

Thanks all,
-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

[Tinycc-devel] Attempt to create a host on ShareSource failed

[KHMan]

Hi all,

I have tried to register a project on http://sharesource.org which
supposedly has Mercurial hosting but failed. The procedure won't
go past Step 1. Later I will try to check with the ShareSource
people on the problem.

Information used in the registration attempt:

shortname: mercurialtcc
fullname: TinyCC on Mercurial
license: GNU Lesser General Public License (GLGPL) (v2.1)

description:
TinyCC on Mercurial is an unofficial Mercurial development
repository used by TinyCC developers, and acts as a patch feeder
to Fabrice Bellard's offical CVS TinyCC tree. TinyCC is a tiny C
compiler.

Perhaps someone else might have better luck. At least I have
tried. Suppose if I succeed in registering a project there, I will
immediately pass ownership to at least two people, since I know
little about running this thingy and about maintaining hg repos.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia



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

[Tinycc-devel] Re: using CVS

[KHMan]

Simon 'corecode' Schubert wrote:
 KHMan wrote:
 Marc Andre Tanner wrote:
 Mike wrote:
 [snip snip]
 [snip snip]
 grischka, what is the state of the CVS sync?
 grischka hasn't replied to this, so I'll say a few words. I have
 sent grischka hg both export-style and log-style patches; he has
 drawn up a preliminary classification list for the patches. I
 haven't checked the Savannah CVS to see if there's anything new in
 there yet.
 
 It's amazing that you are still confident that funneling all patches
 through one person to wind up in CVS is better and more useful than
 using a distributed SCM...  I won't believe it until I see it happening.

Good Lord. Lay off the Red Bull.

I didn't say it will definitely work or that I was confident or
anything like that. I didn't reject distributed SCMs. I only
*suggested* sync'ing hg/git with CVS (as a nod of respect to
Fabrice's position as owner and to make easier the release of new
unstable versions) and I volunteered to *try* to sync Rob's tree.
*That's* *all*. I am *not* *rejecting* distributed SCMs in favour
of CVS at all. In fact, I kept asking when someone will step up
and host a new hg/git tree for semi-official tcc development. I
fully support that. Developers can keep using hg or whatever.
Packagers of tcc can decide to pick whatever they see fit for
packaging. It's not mature enough to be called stable software
anyway, so it's buyers beware.

The (1) attempt (possibly foolish, in my own words) at trying to
sync the CVS, and (2) continuing development using somebody's
Mercurial tree has *absolutely* *nothing* to do with each other.
(2) can proceed regardless what happens to (1). Perhaps if, and I
mean, *if*, it happens to work out well, then (1) might catch up
with (2). If it doesn't, then there are various options open to
the tcc community.

So I am just trying and grischka has volunteered on his own to
deal with the CVS bit. So, please let us give him some time and
stop the pointless and senseless disparaging.

The recent patch and the ensuing discussion means that having a
Mercurial host to pull from and push updates to will be Real Nice.
If only people would take action instead of talk. Updating the CVS
is not an option now. grischka needs some time to get things done.

 Sorry to be negative here, but this is an obvious disadvantage to me.

While I have tried very hard to be neutral, some of you guys keep
making wild assumptions about my purported biases, etc. It seems
to me that some people have problems with such projection of
negativity. For example, in one reply a distributed SCM supporter
kindly tells me:

   I understand that you are not familiar (and seemingly even
   hostile) to the [sic] distributed version control, but you
   don't need to force your view to others.

More projection and speculation, yet that person did not reply to
my discussion about git development models. In fact, given his use
of Linux as an example of distributed git development, hgbook says
Linux is almost fully pull, an even more extreme position than me.
It truly makes me wonder why some people keep projecting such
negative and non-existent perceptions about others.

Instead of having so much negative energy against the sync'ing
attempt, why don't someone register a Mercurial host somewhere so
that everyone can continue work? I did suggest using the official
CVS at first, then I suggested semi-automatic sync'ing later when
it became clear that distributed SCMs are preferred. I have been
suggesting and discussing and people jump all over me with
distorted perceptions. Jesus.

Now that changes may be starting to pile up, somebody should host
a repo where people can pull from, somewhere. Regardless of all
the theoretical talk of branching and distributed development, let
us have that common denominator first. Never mind all the talk
about fully distributed whatever, we need that one host to
continue development. At least one. Anyone?

Well, all the distributed SCM supporters on this list, especially
the vocal ones, should take action... we're all waiting. All of
you guys can continue with tcc development regardless of the CVS
sync'ing effort. So, just get on with it...

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia



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

Re: [Tinycc-devel] TCC crashes on invalid structure reference

[KHMan]

Marc Andre Tanner wrote:
 Mike wrote:
 [snip snip]
 [snip snip]
 grischka, what is the state of the CVS sync?

grischka hasn't replied to this, so I'll say a few words. I have
sent grischka hg both export-style and log-style patches; he has
drawn up a preliminary classification list for the patches. I
haven't checked the Savannah CVS to see if there's anything new in
there yet.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] Sample patch from Mercurial repository

[KHMan]

grischka wrote:
 From: KHMan:
 I will push patches to grischka, and check every few patches with
 Ubuntu make all, and the two trees should come together. 
 
 Do you think it is possible and/or makes sense to extract all 
 changesets from Rob's repo into single patches first, with an 
 automatic script or something?

That's easy to do with hg's export. I am using something like:

  hg export 395

Appears to work. I'll write a perl script to do the job.

 Then we could give names to the patches, put them into some 
 order, group them in sub-directories etc. 

However I think some of David Dodge's patches have already been
applied, and bits of documentation has been updated in CVS, so I
guess that some hg patches will not apply cleanly. I am doing this
on cygwin and using WinMerge for visual diff where necessary.

This weekend I will make some time for it.

As for changesets, my plan is to name them using the revision
numbers, like cvs395.diff. I will keep a set of hg exports, like
hg395.diff. This is to preserve commit order. I'll send you a
tarball of both, a bunch at a time.

I see a lot of work on files like tcc.c, so I assume changesets
need to be applied in order (as the lowest common denominator),
moreso with what appears to be some refactoring work done by Rob.
So, well, perhaps they can be named like
cvs395_Does_foo_bar.diff or something like that. Can the
changesets be mixed about and later applied in non-chronological
order? I'm not sure about this, so I am doing this conservatively.

I'm not really sure about the details part, because I can't really
do any quality assurance or assessment of the patches. I was
thinking, just pump them into the CVS, never mind the details, and
the Mercurial bundle can be the starting point of new development.
After all, I agree that next-generation version control is much
more flexible than plain old CVS. The list only need to agree to
keep pumping patches into the CVS, in order to keep tcc in
virtually one piece.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] Newer tinycc repository?

[KHMan]

Joshua Phillips wrote:
 oh, well, it seems they don't officially support it, but it's still possible:
 http://www.selenic.com/mercurial/wiki/index.cgi/MercurialOnSourceforge
 
 On Wednesday 31 October 2007 17:37:03 Gregg Reynolds wrote:
 On 10/31/07, Joshua Phillips [EMAIL PROTECTED] wrote:
 SourceForge supports Mercurial
 Not according to their documentation.  Do you have a link?

Interesting. According to:

http://en.wikipedia.org/wiki/Comparison_of_free_software_hosting_facilities

git/hg support looks spotty for now...

At the moment, it looks like there is ShareSource and Alioth for
public Mercurial hosting, or a DIY approach such as the above can
be taken. While it is not explicitly disallowed in:

http://sourceforge.net/docman/display_doc.php?docid=4297group_id=1

It would be only polite to ask permission to do this sort of
thing. Is this method explicitly allowed by the SF people? I've
heard of projects being notified that they are not supposed to be
pushing binaries or source tarballs out of there...

To make discussion easier, here are the relevant pages on public
hosting for hg/git:

http://www.selenic.com/mercurial/wiki/index.cgi/ProjectsUsingMercurial
http://git.or.cz/gitwiki/GitProjects

So -- hypothetically -- if we adopt distributed development of tcc
using hg, will this mean that by the openly distributed model, we
expect to have a group of developers who maintain repositories
that are public-access, so that A can pull from B or C or D at any
time?

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] Newer tinycc repository?

[KHMan]

Sanghyeon Seo wrote:
 2007/10/30, KHMan [EMAIL PROTECTED]:
 ... If there is a FLOSS project where commit access
 is *totally* open like a wiki, please let me know, it would be an
 interesting factoid to know.
 
 Linux kernel, Xorg, Wine, etc., in that they are using Git, and anyone
 is free to commit to his local repository. I understand that you are
 not familiar (and seemingly even hostile) to the distributed version
 control, but you don't need to force your view to others.

Dear everyone, I realize this discussion goes into a lot of OT
territory, but since it involves the future of tcc development, I
don't wish to stay silent, and so I will try to clarify the
dissonance to the best of my meagre ability and not chicken out.
:-) The following are some extended comments, my last ones for
now. Hopefully it will make things clearer and not worse.

To clarify the use of git in distributed revision control, IIRC
Linus has said of git that it is sort of a low-level distributed
version control system, or a very fast versioned file system. git
does not try to impose specific development models, but allows for
maximum flexibility. hg also does not seem to impose specific
development models as well. It is up to the developers' discipline
to make development work... or fail.

To claim that git is doing 'dis and 'dat is not enough, because
git is just infrastructure -- it facilitates and does not try to
constrain. What matters in, say, Linux development is the
development model, the social construct that is agreed upon. How
does changes filter into the main tree? When Linus pulls from one
of his lieutenants, what is he assuming? When a module maintainer
pulls from Linus or accepts patches from contributors, what are
his or her assumptions and duties?

Can we then consider the Linux social model to be trivial or
unimportant, and instead consider git by itself to somehow, hold
the magic and the key to distributed development?

git does not impose much of anything; it is the social hierarchy
that counts. Each developer is of course completely free to
personally mess with his own repository (obviously) but here we
are dealing with the entire system as a whole, that is, how to get
tcc development moving among a multitude of mostly casual
contributors with the minimum of effort and fuss and confusion.

There is no total distribution in Linux development. There are
hierarchies and bottlenecks. It is not a cloud of equal peers --
although in theory all are equal from git's viewpoint. Disputes
happen and complaints exist. Features wanting to go into the main
tree are supposed to change in tandem with the main tree, no ifs
or buts. Linus or anyone else will most likely not pull an
obsolete or out-of-date changeset and then spend the time to
update the code for the latest version of the kernel. People who
sign off code are expected to 'had better have seen and reviewed
them code'. There are duties, responsibilities, trust networks,
hierarchies.

Note: All of this says nothing about git itself; it has all to do
with the social rules of Linux development. Likewise, if Linus
suddenly decides to use hg, not that much would change -- because
the intelligence of that system does not lie in git.

Now, I am studying a linux-2.6.21.3 tree, and it's 226MB in size.
tcc is 1.6MB in size. Changesets from differing trees are more
likely to conflict with each other in the latter. One problem is,
tcc.c is a real hot hotspot. Just diff the Savannah CVS and the hg
tip. Say, if you have half a dozen people hacking at tcc.c
separately, splitting off into six branches, I wouldn't want to be
the one merging or pulling from all of those into one place. I
don't have the skills for that -- I still see in the hg documents
that merging might bring up a graphical merging tool for the icky
cases, so no magic wand there.

So, whichever way we want to whack at tcc.c, surely, some form of
coordination is helpful. Thus, I personally would highly prefer a
common denominator to be decided early on, a tree we all agree
upon where people can sync regularly with. I can now pull using
CVS, SVN, git or hg, so I am quite neutral; it's really the social
construct that I am blathering off about.

If my reasoning is wrong, please provide a detailed rebuttal.

Thanks, and that's all for now,
-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] Newer tinycc repository?

[KHMan]

Simon 'corecode' Schubert wrote:
 KHMan wrote:
 If there is a FLOSS project where commit access
 is *totally* open like a wiki, please let me know, it would be an
 interesting factoid to know.
 
 Yes, git/repo.or.cz has this mob branch which is open for anonymous
 pushing.  I like this idea and I think this could turn out to be a
 beneficial development model.  It could also be horrible, sure.

Now that you mention git services, what about this?

https://savannah.gnu.org/maintenance/UsingGit

Anyone knows whether this service is working or not? It's git and
it's on Savannah and it might also serve as, perhaps, an official
migrated tree. Of course, I'm version-control neutral and I'm
totally just speculating. :-)

 [snip]

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] Newer tinycc repository?

[KHMan]

Simon 'corecode' Schubert wrote:
 KHMan wrote:
 so for the third time, I'd say
 that we now need someone to take some kind of lead...
 
 what for?  wikis also work without having somebody declared as the
 leader.  why shouldn't this work for code as well?

Gee, more nitpicking. You *did* say there is a need for a common
denominator. So, I assume there should be postings, talk, action
and eventually the list would *in* *theory* move towards some kind
of common denominator repository, right? And normally there are
some sort of owners, right, even for wikis? Not everybody is going
to get commit access, right? There will be person(s) to send
patches to, right? If there is a FLOSS project where commit access
is *totally* open like a wiki, please let me know, it would be an
interesting factoid to know.

How should I word things without more of this kind of pointless
nitpicking? There seem to be more landmines here than a WWII
minefield. Never mind, I have a really thick skin, and I will
indulge some of you guys for a while.

So -- how shall I say it -- perhaps someone might declare a
Mercurial host (or equivalent) open for business in the near
future, and maybe a wiki (or equivalent) as well. (I assume most
on the list is not keen on Nick's SVN repo.) These are all
community action items, and as far as I can tell, they all
require some level of commitment from someone, somewhere. I was
just wondering aloud when a commitment will appear. That's
reasonable, right?

That was all I was suggesting/wondering/hoping/pondering. Really.
Do lay off the Red Bull. :-)

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia



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

Re: [Tinycc-devel] Newer tinycc repository?

[KHMan]

Sanghyeon Seo wrote:
 2007/10/30, KHMan [EMAIL PROTECTED]:
 ... If there is a FLOSS project where commit access
 is *totally* open like a wiki, please let me know, it would be an
 interesting factoid to know.
 
 Linux kernel, Xorg, Wine, etc., in that they are using Git, and anyone
 is free to commit to his local repository. I understand that you are
 not familiar (and seemingly even hostile) to the distributed version
 control, but you don't need to force your view to others.

Please discuss push and pull models separately, and give a little
more detail. Linus will not pull from any stranger, and there is
push at the edges. Pull requires trust of quality or verification
of work. The latter is non-trivial. The former requires
relationships to be established. Promiscuous pull entails risk. A
wiki is more akin to a push model, where commits are totally open.
Never seen a pull wiki yet... I can't really see it being equated
with git or hg. Of course, I welcome actual examples.

You have given some examples. Can you be more specific? Simon
mentioned wikis as a analogue; are there close equivalent models
in revision control? I fail to see how you can use Linux as an
example. It's sorta distributed, but the trust hierarchy is
non-trivial. Thus, it's hard to equate that with a totally open
model that I believe Simon is trying to paint. I'm assuming this
community wishes to maximize economic utility for all by trying to
stick to one true tree.

Yeah, perhaps the magical sharing of changesets is the holy
grail of revision control, but the fact that you can
automatically merge in a changeset from a significantly different
tree does not say anything about whether the source is still
correct, or subtly broken. Everyone still falls back to manual
merge when things go wrong. There is still a desire to not diverge
too much if one is to still work on essentially the same branch,
so we often have what Simon calls a common denominator, thus
there will be a trust hierarchy.

Both Simon and you seem to be in academia, so I sorta expect
stronger and more persuasive arguments.

Thanks for the feedback,
-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia



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

Re: [Tinycc-devel] Newer tinycc repository?

[KHMan]

Simon 'corecode' Schubert wrote:
 KHMan wrote:
 If there is a FLOSS project where commit access
 is *totally* open like a wiki, please let me know, it would be an
 interesting factoid to know.
 
 Yes, git/repo.or.cz has this mob branch which is open for anonymous
 pushing.  I like this idea and I think this could turn out to be a
 beneficial development model.  It could also be horrible, sure.

Yeah, I know it all sounds cool and I'm a killjoy. :-) Engineers
are conservative, we're trained like that. Nothing wrong with
either view. Bernhard Fischer wrote in the other e-mail: patches
can be journaled into for discussion and review. I hope someone
actually takes responsibility for discussion and review because
assumptions (jumping to the Island of Conclusions in the
parlance of Norman Juster) is quite a short step from disaster.
Here, we probably won't get people killed, but still...

Distributed version control is sometimes pushed like Web 2.0.
I find it sorta disturbing. I'm more concerned about quality
assurance and maximizing the use of what little resources that we
have.

 I didn't want to bring up the topic of hg vs git, but there is a public
 git hosting site (repo.or.cz) which helps making progress without
 somebody dedicated providing the infrastructure.

I'm totally neutral. :-) Just waiting for an announcement...

 [snip]
 Don't get me wrong, this is not personal.  It's just about the
 conceptual model of code access.  You propose a single authority, I
 propose a completely distributed model where maybe eventually there will
 be one repo which a fraction of the users will consider as current or
 stable enough.

No offense taken, of course. I've thought about the details, but
I'm unsure about execution, that's the reason for my skepticism.
Sure, theoretically a completely distributed model, but I don't
believe I've seen a posting announcing availability of a new
Mercurial repo for sharing yet. I've now got Mercurial installed
myself, but I won't want to maintain a public access node. So
AFAIK I don't think you can pull from me, right? How many repos
will one be able to pull from, anyway, since there seem to be a
dearth of available repos so far? That's the little problem I see
with the scenario: your model has no announced nodes so far.
Moreover, once I send exported changesets to you, it becomes push.

So, to simplify, I propose that we can anoint the first hero to
declare his repo open for business as the temporary focal point
or common denominator.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] Sample patch from Mercurial repository

[KHMan]

Dave Dodge wrote:
 On Mon, Oct 29, 2007 at 02:59:15AM +0800, KHMan wrote:
 Attached is a sample patch based on the Mercurial repository. I
 assume revisions up to 395 is already in the official CVS,
 
 Just a quick note about mercurial: revision numbers such as 395 are
 just a convenience and are locally assigned to each copy of the
 repository.  They aren't guaranteed to be the same for each user; in
 fact local commits will quickly knock them out of sync.  Changeset IDs
 such as f357b2f8add5 _are_ kept globally consistent, so if you want to
 specify a particular change you can use those.

Thanks, I understand, I know some git and I am reading hgbook now.
It was just more convenient with those numbers assuming Seo's
Mercurial bundle is a frozen unit. I guess hg/git people can
correctly say that my brain has been lobotomized by the notion of
SVN revision numbers... :-)

I will be contacting David Wheeler to see if he is interested in
accepting them patches.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] Newer tinycc repository?

[KHMan]

Sanghyeon Seo wrote:
 2007/10/27, Daniel P. Stasinski [EMAIL PROTECTED]:
 With Rob Landley quitting and now deleting his own tinycc repository,
 is there any other site that hosts all the known patches and/or
 tarball.
 
 I have a clean checkout, which thanks to the distributed nature of
 Mercurial, is as good as the repository itself.
 
 I exported the checkout as Mercurial bundle and uploaded it here:
 http://sparcs.kaist.ac.kr/~tinuviel/download/tinycc.bundle
 
 To use it:
 hg init tinycc
 cd tinycc
 hg unbundle ../tinycc.bundle
 hg update

Okay, never mind about my last post. I'm looking at just under 100
changesets (from the start of Rob's commits) in Seo Sanghyeon's
bundle. The timestamp on the last changeset is: Wed Oct 03
18:15:48 2007 -0500

Looks like some pretty extensive changes, including directory
structure changes and refactoring. The question now is: Should all
of Rob's tree go into the official CVS?

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia



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

[Tinycc-devel] Sample patch from Mercurial repository

[KHMan]

Hi all,

Attached is a sample patch based on the Mercurial repository. I
assume revisions up to 395 is already in the official CVS, so
perhaps I shall try and see how many trivial patches I can make
from revision 396 onwards, versus current Savannah CVS. No quality
assurance beyond trying a make all on Ubuntu. Comments?

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia

# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1160276413 14400
# Node ID 928147ea8ab65f7f295692021e37586251c3bce6
# Parent  f357b2f8add53b403bfe7edd71c519b4709a1515
Fix invalid relocation entry problem on ubuntu.  Fix from Bernhard
Fischer: http://lists.gnu.org/archive/html/tinycc-devel/2005-09/msg00051.html

diff -urN tinycc_cvs/tccelf.c tinycc_new/tccelf.c
--- tinycc_cvs/tccelf.c 2007-10-29 00:03:55.171875000 +0800
+++ tinycc_new/tccelf.c 2007-10-29 02:38:33.296875000 +0800
@@ -1874,7 +1874,6 @@
 
 /* second short pass to update sh_link and sh_info fields of new
sections */
-sm = sm_table;
 for(i = 1; i  ehdr.e_shnum; i++) {
 s = sm_table[i].s;
 if (!s || !sm_table[i].new_section)
@@ -1888,6 +1887,7 @@
 s1-sections[s-sh_info]-reloc = s;
 }
 }
+sm = sm_table;
 
 /* resolve symbols */
 old_to_new_syms = tcc_mallocz(nb_syms * sizeof(int));
@@ -1949,9 +1949,11 @@
 if (sym_index = nb_syms)
 goto invalid_reloc;
 sym_index = old_to_new_syms[sym_index];
-if (!sym_index) {
+   /* ignore link_once in rel section. */
+if (!sym_index  !sm-link_once) {
 invalid_reloc:
-error_noabort(Invalid relocation entry);
+error_noabort(Invalid relocation entry [%2d] '%s' @ %.8x,
+i, strsec + sh-sh_name, rel-r_offset);
 goto fail;
 }
 rel-r_info = ELF32_R_INFO(sym_index, type);
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Newer tinycc repository?

[KHMan]

[sorry if this is sent twice, I'm in between switching e-mails]

Sanghyeon Seo wrote:
 2007/10/27, Kein-Hong Man [EMAIL PROTECTED]:
 Speaking as a lurker... Now that Mercurial isn't a do-or-die
 requirement on the part of the maintainer, is it possible that the
 tcc community go back to the official repository? David Wheeler
 already has access to it. Lots of CVS/SVN users still get by...
 
 What's wrong with Mercurial?

The official repository is not Mercurial, I believe. There is no
reason to continue with another fork now, is there? Given a
choice of (1) starting another Mercurial repository of tcc or (2)
working with the official repository and aim for a 0.9.24 release,
as a fairly neutral bystander, I definitely prefer to see the
latter. It will also make the work of all the package maintainers
easier, no more ambiguity.

The bigger issue is not which repository to use, it is for someone
experienced to step up to lead and move the project forward and
stick to it for some time. Since tcc itself does not have any
religious issues to stop it from becoming a single entity again,
an inclusive stance would be nice. The lowest common denominator
is probably not sexy for some people, but it provides the lowest
barrier to participation.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia



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