> A purpose for everything, and for everything a purpose. C is a
> difficult language to write big programs in, most of all because you
> have to do all memory management yourself (non-cyclic dependencies
> make this easy, cyclic dependencies make this hard, data outside of
> basic foundations such
> Date: Thu, 26 Sep 2013 11:33:38 +0200
> From: Sylvain BERTRAND
> To: tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] inline assembly and optimization passes
> Message-ID: <20130926093338.GA500@freedom>
> Content-Type: text/plain; charset=us-ascii
>
>>
On Wed, Sep 25, 2013 at 09:23:58PM -0500, Jared Maddox wrote:
> > Yes, as you got below I meant removing functions such as
> >
> > if (0)
> >some_function();
> >
> > The "problem" is that many applications use this construct instead of
> > adding #ifdefs everywhere.
>
> So I've heard. Just use
> So that was in response to the "if I were implementing a language
> from scratch" bit, right?
yes
> If I was doing that then I'd be looking at an application
> language that would easily integrate with a systems language,
> hence high-end features along with C compatibility.
>
> If I was going
> Date: Tue, 24 Sep 2013 05:31:40 +0200
> From: Sylvain BERTRAND
> To: tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] inline assembly and optimization passes
> Message-ID: <20130924033140.GG754@freedom>
> Content-Type: text/plain; charset=us-ascii
>
>>&
Jared Maddox wrote:
decl( ) comes from tccgen.c, and looks like the bottom-level function
in the parser proper.
true.
I ASSUME that when it finishes, you'll have a
ready-to-use parse tree in the active TCCState.
false. TCC translates to machine code immediately while it reads
along the
>>> Thoughts?
>>
>> Wow... :) You totally missed my point.
>>
>> My idea is to have a langage which has a lower implementation
>> technical cost. That's why I was saying "the other way".
> >
>
> Are you talking about the IL/IC, or the other one we were talking
> about? Because I talked about two t
> Date: Mon, 23 Sep 2013 14:22:16 +0200
> From: Sylvain BERTRAND
> To: tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] inline assembly and optimization passes
> Message-ID: <20130923122216.GB754@freedom>
> Content-Type: text/plain; charset=us-ascii
>
>> Th
On Mon, Sep 23, 2013 at 05:05:35PM +0200, Vittorio Giovara wrote:
> On Mon, Sep 23, 2013 at 3:45 PM, Thomas Preud'homme wrote:
>> Le lundi 23 septembre 2013 14:31:04 Vittorio Giovara a écrit :
>>>
>>> In my opinion, tinycc can remain without optimizations because it is
>>> not one of the compiler
On Mon, Sep 23, 2013 at 3:45 PM, Thomas Preud'homme wrote:
> Le lundi 23 septembre 2013 14:31:04 Vittorio Giovara a écrit :
>>
>> In my opinion, tinycc can remain without optimizations because it is
>> not one of the compiler design goals.
>> However there is one optimization that's more like a fe
> In my opinion, tinycc can remain without optimizations because it is
> not one of the compiler design goals.
Yes, it's very important the optimization passes disrupt the
least possible the internals of tcc, we all agree on that. That's
why a new independent target would be a very good idea, and
Le lundi 23 septembre 2013 14:31:04 Vittorio Giovara a écrit :
>
> In my opinion, tinycc can remain without optimizations because it is
> not one of the compiler design goals.
> However there is one optimization that's more like a feature these
> days: dead code elimination.
> There are quite a fe
On Fri, Sep 20, 2013 at 3:08 AM, Sylvain BERTRAND wrote:
> Hi,
>
>
>
> I wonder if the internals of tinycc can easily supports basic
> optimization passes. The idea is not to compete with gcc and its
> hundred of passes, but my guess is that very few optimization
> passes would be required to
> Sorry about the delay, I receive digests, so I didn't get this until
> after I'd sent out my last message.
>
> The reason why C is normally not used as an IL/IC is because you can
> design languages that are easier to parse than C. Simple as that. Your
> stereo typical assembly language, where e
> Thoughts?
Wow... :) You totally missed my point.
My idea is to have a langage which has a lower implementation
technical cost. That's why I was saying "the other way".
--
Sylvain
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.n
> Date: Sun, 22 Sep 2013 18:39:00 +0200
> From: Sylvain BERTRAND
> To: tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] inline assembly and optimization passes
> Message-ID: <20130922163900.GC741@freedom>
> Content-Type: text/plain; charset=us-ascii
>
> On S
> Date: Sun, 22 Sep 2013 16:39:14 +0200
> From: Sylvain BERTRAND
> To: tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] inline assembly and optimization passes
> Message-ID: <20130922143914.GB741@freedom>
> Content-Type: text/plain; charset=us-ascii
>
> :)
On Sat, Sep 21, 2013 at 12:02:58AM -0500, Jared Maddox wrote:
> I recently bought a copy of the "Dragon Book", and according to
> it, optimization passes are usually performed on an AST that is
> created from a compiler-specific intermediate code: in essence, a
> specialized byte code or assembly c
:)
If I were to design a new language, I would go the other way,
less complex, more explicit.
I would go for a kind of C99- language (C-- is already taken by a
great evil):
- only sized types (u8 s16 f80...), no void pointer
- kind of no implicit cast (use of aliasing)
- no typedef
- no enum
> Date: Sat, 21 Sep 2013 14:36:50 +0200
> From: Thomas Preud'homme
> To: tinycc-devel@nongnu.org
> Cc: Jared Maddox
> Subject: Re: [Tinycc-devel] inline assembly and optimization passes
> Message-ID: <1808697.keR0AihLx1@trevize>
> Content-Type: text/plain; chars
On Sat, Sep 21, 2013 at 02:36:50PM +0200, Thomas Preud'homme wrote:
> Le samedi 21 septembre 2013 00:02:58 Jared Maddox a ?crit :
> > > Date: Fri, 20 Sep 2013 15:50:28 +0200
> > > From: Thomas Preud'homme
> > > To: tinycc-devel@nongnu.org
> > >
Le samedi 21 septembre 2013 00:02:58 Jared Maddox a écrit :
> > Date: Fri, 20 Sep 2013 15:50:28 +0200
> > From: Thomas Preud'homme
> > To: tinycc-devel@nongnu.org
> > Subject: Re: [Tinycc-devel] inline assembly and optimization passes
> > Message-ID: <197595
> Date: Fri, 20 Sep 2013 15:50:28 +0200
> From: Thomas Preud'homme
> To: tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] inline assembly and optimization passes
> Message-ID: <1975955.xx8PpmsNzB@cerclon>
> Content-Type: text/plain; charset="iso-8859-1&quo
Le vendredi 20 septembre 2013 16:42:21 Sylvain BERTRAND a écrit :
>
> > There is already inline assembly in tcc for i386 and x86-64.
> > However, the support is not fully complete.
>
> Oops! I thought the x86-64 backend has no inline assembly but
> generated directly machine code. My bad (or last
On Fri, Sep 20, 2013 at 3:50 PM, Thomas Preud'homme wrote:
> negligeable, I think adding it to tcc is not a good idea. Many people are
> interested in tcc because of its fast compilation so I would say it's more
> important to keep it fast than to make the generated code better.
>
+1
i recently
> I'm not familiar with optimization but I would guess it would
> have a non negligeable impact on tcc's performance. If you want
> basic optimization you could try -O1 switch of gcc or clang.
> Unless the cost of an optimization is negligeable, I think adding
> it to tcc is not a good idea. Many p
Le vendredi 20 septembre 2013 03:08:10 Sylvain BERTRAND a écrit :
> Hi,
>
>
>
> I wonder if the internals of tinycc can easily supports basic
> optimization passes. The idea is not to compete with gcc and its
> hundred of passes, but my guess is that very few optimization
> passes would be r
Hi,
I wonder if the internals of tinycc can easily supports basic
optimization passes. The idea is not to compete with gcc and its
hundred of passes, but my guess is that very few optimization
passes would be required to give a significant performance boost
to generated code. Just need to se
28 matches
Mail list logo
