What's the best way to learn about developing GCC? Not developing in
GCC, but understanding and extending the compiler's design itself?
Thanks,
Rick C. Hodgin
size. This extra space would
allow for a certain number of new variables before a full recompile is
required again. We could also have #pragma-like statements for
individual functions where we know some heavy changes will be used, to
give them an extra 512 bytes, or whatever's specified.
- Rick
t instead calls a known location in memory that is rigid and
unchanging always, which itself references either dynamically updated
code as needed, or calls a reference into a memory-based table which
points to the new function locations.
Just my thoughts.
- Rick C. Hodgin
ys miss it.
Simple little mistakes like:
for (i=0; i On 18 July 2010 20:52, Rick C. Hodgin wrote:
> >
> > The idea of having function entry points across the board for all
> > executed code would be required, allowing those links to be updated
> > dynamically at run-time. We co
All,
Is there an Intel-syntax compatible option for GCC or G++? And if not,
why not? It's so much cleaner than AT&T's.
- Rick C. Hodgin
tax commands all failed after that. So, this directive
must be a global setting, and not an instance-by-instance setting.
Thanks for the search, Tim. :-)
- Rick
On Sun, 2010-08-08 at 23:37 -0700, Tim Prince wrote:
> On 8/8/2010 10:21 PM, Rick C. Hodgin wrote:
> > All,
> >
> >
> "Rick C. Hodgin" writes:
> > Is there an Intel-syntax compatible option for GCC or G++? And if not,
> > why not? It's so much cleaner than AT&T's.
> -masm=intel
> This question would have been more appropriate on the gcc-help mailing
> list. -Ia
dded feature, being maintained
from here on out -- by me at first, but whoever else would want to do it
at some point.
Any thoughts? Thank you in advance.
- Rick C. Hodgin
- Email me for phone contact info if you want to talk to me personally.
> Most of the interesting bits happen in the linker+debugger...
Agreed, which is why the compiler side doesn't matter much in terms of
how much it does, just so long as it is correct and compliant. This is
the hard part I'm finding, which is why I'm looking to the GCC community
which spends a gre
> ;; %%% bts, btr, btc, bt.
> ;; In general these instructions are *slow* when applied to memory,
> ;; since they enforce atomic operation. When applied to registers,
>
> I haven't found documented confirmation that these instructions are atomic
> without a lock prefix,
> having checked Intel and
> > They do not automatically lock the bus. They will lock the bus with the
> > explicit LOCK prefix, and BTS is typically used for an atomic read/write
> > operation.
> Thanks Rick.
> I'll go back to using them.
> I'm optimizing mainly for size.
> The comment should perhaps be amended.
> The "sin
monstrates that to call each
function it's in again that it can be done without knowing the function
name.
Best regards,
Rick C. Hodgin
Ian,
I was thinking C and C++.
int myclass::foo(int a)
{
// recursion
self(a + 1);
}
Just out of curiosity, why wouldn't it be accepted back into mainline?
Thanks for your help. :-)
Best regards,
Rick C. Hodgin
On 06/14/2012 12:48 PM, Ian Lance Taylor wrote:
"Rick
name substitution.
Best regards,
Rick C. Hodgin
On 06/14/2012 01:08 PM, David Malcolm wrote:
FWIW "self" today is a perfectly good variable name, and practically all
C and C++ code that interacts with Python (including the C
implementation of Python itself) uses "self" to
)"
message function, which could just be a requirement of the app to always
be there. The rest, however, could be fluid.
A few other uses I can think of as well. Minor ones.
Best regards,
Rick C. Hodgin
On 06/14/2012 04:24 PM, David Brown wrote:
On 14/06/12 19:31, Joe Buck wrote:
It o
Andreas,
That would work. But now I'm back to remembering to fix something when
I copy / re-use code.
I'll admit it's minor. But we have tools to help us for a reason,
right? :-)
Best regards,
Rick C. Hodgin
On 06/14/2012 04:38 PM, Andreas Schwab wrote:
"Rick C.
regards,
Rick C. Hodgin
Original Message
From: Václav Zeman
Sent: Fri, Jun 15, 2012 08:08 AM
To: Oleg Endo
CC: Rick C. Hodgin ; David Brown
; Joe Buck ; Ian Lance
Taylor ; gcc@gcc.gnu.org
Subject: Re: "self" keyword
>On 14 June 2012 22:42, Oleg Endo wrote:
ition natively. x86 has
the SETcc instructions, for example, which are native to this concept. ARM has
predicates. It is already there at the CPU level.
Best regards,
Rick C. Hodgin
Original Message
From: James Dennett
Sent: Thu, Jun 28, 2012 04:14 PM
To: Rick Hodgin
than need be.
This is my last comment on the post. It's just that I just believe that
anything worth doing is worth doing rightly, and completely. Not having native
inverse bool support seems incomplete to me.
Best regards,
Rick C. Hodgin
Original Message
From: James De
19 matches
Mail list logo
