On Tue, Apr 17, 2012 at 2:52 AM, Oleg Endo wrote:
> On Mon, 2012-04-16 at 04:11 +0800, Chiheng Xu wrote:
>> On Sat, Apr 14, 2012 at 11:47 AM, Chiheng Xu wrote:
>> >
>> > And I want to say that tree/gimple/rtl are compiler's data(or state),
>> > not comp
On Sat, Apr 14, 2012 at 7:07 PM, Robert Dewar wrote:
> hand, but to suggest banning all templates is not a supportable
> notion.
>
Why ?
--
Chiheng Xu
e->field_of_base_type" does not
work. You must use "p_derived_type->m_base_type.field_of_base_type" .
For multilevel of derivation, the expression is even longer.
Apparently, this is not as clear as
FIELD_OF_BASE_TYPE(p_derived_type).
But once you use C++, there will be no such trouble.
"p_derived_type->field_of_base_type" just works regardless of the
levels of derivation !
--
Chiheng Xu
On Sat, Apr 14, 2012 at 11:47 AM, Chiheng Xu wrote:
>
> And I want to say that tree/gimple/rtl are compiler's data(or state),
> not compiler's text(or logic), the most important thing about them is
> how to access their fields.
>
Given the above assumption, now I doubt
On Sat, Apr 14, 2012 at 5:08 PM, Robert Dewar wrote:
> On 4/13/2012 9:15 PM, Chiheng Xu wrote:
>
>> So, I can say, most of the GCC source code is in large files.
>>
>> And this also hold for language front-ends.
>
>
> I see nothing inherently desirable about havi
On Sat, Apr 14, 2012 at 5:09 PM, Robert Dewar wrote:
> On 4/13/2012 9:34 PM, Chiheng Xu wrote:
>>
>> On Wed, Apr 4, 2012 at 7:38 PM, Richard Guenther
>> wrote:
>>>
>>>
>>> Oh, and did we address all the annoyances of debugging gcc when it's
&
On Sat, Apr 14, 2012 at 9:15 AM, Chiheng Xu wrote:
> The rest, 440 or so of them, is below 50 KB, which contribute 75% of
The rest, 440 or so of them, is below 50 KB, which contribute 25% of
--
Chiheng Xu
a virtual
> pointer field. Those data structures are heavily optimized for memory
> footprint.
> Not to mention it is very questionable if the above stuff is more readable
> than what we currently have.
>
And I want to say that tree/gimple/rtl are compiler's data(or state),
not compiler's text(or logic), the most important thing about them is
how to access their fields.
--
Chiheng Xu
gt; cost as well. E.g. all such changed data structures grow by a virtual
> pointer field. Those data structures are heavily optimized for memory
> footprint.
> Not to mention it is very questionable if the above stuff is more readable
> than what we currently have.
>
Agree.
--
Chiheng Xu
e that the conversion needs to provide value. Vectors
>> and hash tables are a good early target.
>
> Hash tables? Ugh, what is wrong with the hash tables we have right now in
> GCC?
>
He probably mean to wrap hash table in C++ class.
--
Chiheng Xu
{
var_decl * p_var_decl = (var_decl *) p;
do_var_work_1 (p_var_decl);
}else if(is_type_decl(p)){
type_decl * p_type_decl = (type_decl *) p;
do_type_work_2 (p_type_decl);
}else if(is_field_decl(p)){
field_decl * p_field_decl = (field_decl *) p;
do_field_work_3 (p_field_decl);
}
--
Chiheng Xu
thod_1()
{
}
derived_type::getter_2()
{
}
derived_type::setter_2()
{
}
derived_type::method_2()
{
}
--
Chiheng Xu
ll not have such
annoyances.
--
Chiheng Xu
total source file size of the directory.
The rest, 440 or so of them, is below 50 KB, which contribute 75% of
the total source file size of the directory. Some of this files are
so small that some merging is needed.
So, I can say, most of the GCC source code is in large files.
And this also hold for language front-ends.
--
Chiheng Xu
ite wrapper API
in C++, namely MFC. I mean , to provide a C style API and provide a
C++ wrapper library for this API, then you can use both C and C++ in
you plug-in.
As for experimenting C++ in GCC, I suggest , at first, using C++ only
in the internal of a pass implementation or a module, not exposing
C++ interface to other part of code. Namely, the interfaces between
between modules are still C, but he implementations can be written in
either C or C++ or both.
And I predict that C++ will not have any positive impact on
performance(compile time or run time).
--
Chiheng Xu
gt;
I'll try it if I have enough time . Thank you!
--
Chiheng Xu
ssential books since
> the year of its publication, and my other daytime job essentially relies GC.
>
I'm really sorry for the misunderstanding.
The only reason I refer to that book, is that, my English is not
fluent enough to clearly explain my opinion. That book said all I
want to say.
found GCC's source code was not that
horrible. It turned out to be simple and easy to understand
"suddenly".
My point is that, when a programmer don't need to worry about memory
management issue, his/her productivity is maximized.
--
Chiheng Xu
gcc_clean_scripts.tar.bz2
Description: BZip2 compressed data
g splay tree.
--
Chiheng Xu
Wuhan,China
hashing. 20 comparisons may be faster than
1 hashing.
--
Chiheng Xu
Wuhan,China
n is that a garbage collector is (or can become) a proper memory
> manager.
> If you really want to switch back to manual memory management, please be
> sure to make changes which will be easy to revert.
> I believe that the current GCC garbage collector could be improved (but that
> is very hard work!)
>
Agree.
--
Chiheng Xu
Wuhan,China
e repositories
persistently, and can revive at any time.
If someone's branch diverge far from the trunk, it may be very hard to
merge. So branches from a relatively newer trunk revision and have not
too many changes will be desirable.
In this method, you only need to note the branch(and its URL) to
review, instead of attach the patches.
By the way, I found mercurial are easier to learn and use.
--
Chiheng Xu
Wuhan,China
the branches the patches reside.
If you use mercurial or git, every change will not be lost, every one
can review and selectively merge any branch on his/her convenience.
--
Chiheng Xu
Wuhan,China
23 matches
Mail list logo
