Re: [Tinycc-devel] Preprocessor performance tuning

[Sergey Korshunoff]

>> Here is a patch that tweaks it to use separate static CString buffer
>Don't helped.

Fixed on [mob]. Please verify.

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

Re: [Tinycc-devel] Preprocessor performance tuning

[Sergey Korshunoff]

> Here is a patch that tweaks it to use separate static CString buffer
Don't helped.

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

Re: [Tinycc-devel] Development style

[David Mertens]

Hello Michael,

I committed the revert. Based on what I see at the gitweb for the mob
branch (http://repo.or.cz/tinycc.git/shortlog/refs/heads/mob), it's not
there. I don't see anything between Vlad's commit and the one you pushed an
hour ago.

David

On Fri, Apr 22, 2016 at 9:43 AM, Michael Matz  wrote:

> Hello David,
>
> On Mon, 18 Apr 2016, David Mertens wrote:
>
> > I have nuked that commit.
>
> Thank you for that.  (But you haven't yet committed the revert, right?)
>
> > For time management reasons, my recreational programming goes through a
> > distinct email account, one that I hadn't checked since early January.
> > It might have looked as though I had abandoned my work on exsymtab. I
> > have not, I just put it on hiatus. Today happens to be the day I've
> > checked back, and wow, what a day.
>
> ;-)
>
>
> Ciao,
> Michael.
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "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
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Development style

[Michael Matz]

Hello David,

On Mon, 18 Apr 2016, David Mertens wrote:

> I have nuked that commit.

Thank you for that.  (But you haven't yet committed the revert, right?)

> For time management reasons, my recreational programming goes through a 
> distinct email account, one that I hadn't checked since early January. 
> It might have looked as though I had abandoned my work on exsymtab. I 
> have not, I just put it on hiatus. Today happens to be the day I've 
> checked back, and wow, what a day.

;-)


Ciao,
Michael.

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

Re: [Tinycc-devel] tcc as compiler for tccboot

[Michael Matz]

Hi,

On Wed, 20 Apr 2016, Sergey Korshunoff wrote:

> > Just checked. I used a hex editor to replace a 0x20 bytes in mem-2.o with 
> > 0x04.
> > This helped.
> 
> diff --git a/libtcc.c b/libtcc.c
> index 5aebd32..a8e109c 100644
> --- a/libtcc.c
> +++ b/libtcc.c
> @@ -514,7 +514,11 @@ ST_FUNC Section *new_section(TCCState *s1, const
> char *name, int sh_type, int sh
>  sec->sh_addralign = 1;
>  break;
>  default:
> +#ifdef TCC_TARGET_I386
> +sec->sh_addralign =  4; /* gcc/pcc default alignment for i386 */
> +#else
>  sec->sh_addralign = 32; /* default conservative alignment */
> +#endif
>  break;

A nicer default that will work for all our architectures is 'PTR_SIZE'.

The 32 comes from Fabrices original tcc implementation, at which point you 
couldn't yet specify alignment for decls (or sections) explicitely, and 
some needed larger alignment than pointer sizes.  This isn't the case 
anymore, section alignment is updated as needed.  So reducing to something 
sensible is possible now.

Please go with PTR_SIZE and no #ifdefery.


Ciao,
Michael.

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

Re: [Tinycc-devel] tcc as compiler for tccboot

[Sergey Korshunoff]

> In any event, it is odd to me that any software compiled entirely from source
> should care about this sort of alignment. It should leave such issues up to
> the compiler, as an implementation detail, shouldn't it?

In the source code we can ask about a section where to place result,
an alignment
of the result, but not alignment (padding) of the section itself. I.e.
how sections of the
same name (from different source code) are combined.

PS: A description of the linux initial code: a name (pointer) of the
init function is placed in
the special section. And after kernel start this functions are called.
If section padding
is more then sizeof(pointer), then there are null pointers and we have a trap

A special section for this is used to free memory after start (no need
after start).

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