View mode: basic / threaded / horizontal-split · Log in · Help
May 07, 2012
Re: GSOC Linker project
I think it was there where I read about it.

I'll update you if I have any success, otherwise I need to retract my 
statement. :(

--
Paulo

"Jens Mueller"  wrote in message 
news:mailman.380.1336380192.24740.digitalmars-d@puremagic.com...

Paulo Pinto wrote:
> On Monday, 7 May 2012 at 07:26:44 UTC, Jens Mueller wrote:
> >Paulo Pinto wrote:
> >>AST/symbol table manipulation is way faster than reparsing code.
> >>
> >>People keep talking about D and Go compilation speed, while I
> >>was already
> >>enjoying such compile times back in 1990 with Turbo Pascal in
> >>computers much
> >>less powerfull than my laptop.
> >>
> >>But C and C++ with their 70's compiler technology, somehow won
> >>the
> >>market share,
> >>and then people started complaining about compilation speeds.
> >>
> >>Adele Golberg, once wrote a paper telling how C made the
> >>compiler technology
> >>regress several decades.
> >
> >Do you happen to remember to exact title of that paper?
> >Thanks.
> >
> >Jens
>
> I'll try to find it, as I don't recall the title.
>
> I just remember that it made some remarks how primitive C was in
> regard
> to Algol toolchains.

Many thanks.
I couldn't find it myself and I'm interested because Fran Allen said
something similar in Coders at Work.
I didn't understand what she meant. Andrei suggested that it is mostly
(only?) about overlapping pointers to memory. I'm just curious.

Jens
May 07, 2012
Re: GSOC Linker project
On 07-05-2012 14:50, Steven Schveighoffer wrote:
> On Mon, 07 May 2012 07:41:43 -0400, Alex Rønne Petersen
> <xtzgzorex@gmail.com> wrote:
>
>> On 07-05-2012 13:21, Steven Schveighoffer wrote:
>>> On Fri, 04 May 2012 20:30:05 -0400, Alex Rønne Petersen
>>> <xtzgzorex@gmail.com> wrote:
>>>
>>>> Purity inference won't happen either way. Purity is part of your API
>>>> and also meant to help you reason about your code. If the compiler
>>>> just infers purity in a function and you later change the
>>>> implementation so it's no longer pure, you break your users' code.
>>>> Also, purity would no longer help you reason about your code if it's
>>>> not explicit.
>>>
>>> It can be pure for the purposes of optimization without affecting code
>>> whatsoever. Inferred purity can be marked separately from explicit
>>> purity, and explicitly pure functions would not be allowed to call
>>> implicitly pure functions.
>>>
>>> -Steve
>>
>> But that kind of inferred purity is something a compiler back end
>> cares about, not something the language should have to care about at
>> all. In practice, most compilers *do* analyze all functions for
>> possible side-effects and use that information where applicable.
>
> It affects how callers code will be generated.
>
> If I have a function
>
> int foo(int x);
>
> and I have another function which calls foo like:
>
> int y = foo(x) + foo(x);
>
> Then the optimization is applied to whatever function this exists in. If
> the source isn't available for foo, the compiler cannot make this
> optimization.
>
> I have no idea if this is a back-end or front-end issue. I'm not a
> compiler writer. But I do understand that the compiler needs extra
> information in the signature to determine if it can make this optimization.
>
> -Steve

OK, point taken; didn't consider that. But in the first place, for 
inference of purity to work, the source would have to be available. 
Then, that inferred property has to be propagated somehow so that the 
compiler can make use of it when linking to the code as a library...

-- 
- Alex
May 07, 2012
Re: GSOC Linker project
I like the idea, need to check what information I could provide.

Wirth's books about Oberon also provide similar information.

--
Paulo

"dennis luehring"  wrote in message news:jo85t1$1n9b$1@digitalmars.com...

Am 07.05.2012 07:53, schrieb Paulo Pinto:
> I really really think that mankind did a wrong turn when C won over Pascal
> in the 80's.
>
> And that Wirth somehow lost interest in the industry and did not try to 
> push
> Modula-* or Oberon. There are some papers where he states this.
>
> Now we suffer from
>
> - daggling pointers
> - buffer overflows
> - pre-historic compiler toolchains
>
> With luck, Spec#, Go or more nicely D, will put us back on track.

we should collect all the advantages of turbo pascal/delphi
object-file-formats and make a small description post to show others in
a clear understandable way how good/and longlife these technics are

so the unit-system (turbo pascal: .pas -> .tpu, delphi: .pas->.dcu, free
pascal: .pas -> ppu), the tpumover, ppumover for tpl or ppl libraries,
the dll delphi solution .bpl

and the advantage of controling the output of source inside the source
program -> exe, unit -> object, library -> dynamic libray etc.

any ideas how to start?
May 07, 2012
Re: GSOC Linker project
On Mon, 07 May 2012 09:22:05 -0400, Paulo Pinto <pjmlp@progtools.org>  
wrote:

> This just confirms what I saw yesterday on a presentation.
>
> Many developers re-invent the wheel, or jump to the fad technology of the
> year, because they don't have the knowledge of old already proven  
> technologies,
> that for whatever reason, are no longer common.
>
> We need better ways to preserve knowledge in our industry.

Again, don't take offense.  I never suggested Java's use of an already  
existing technology was in some way a "new" thing, just that it proves it  
can work.

I'm sure back in the day, TurboPascal had to walk uphill through the snow  
to school both ways too. :)

-Steve
May 07, 2012
Re: GSOC Linker project
On Mon, 07 May 2012 09:27:32 -0400, Alex Rønne Petersen  
<xtzgzorex@gmail.com> wrote:

> On 07-05-2012 14:50, Steven Schveighoffer wrote:
>> On Mon, 07 May 2012 07:41:43 -0400, Alex Rønne Petersen
>> <xtzgzorex@gmail.com> wrote:
>>
>>> On 07-05-2012 13:21, Steven Schveighoffer wrote:
>>>> On Fri, 04 May 2012 20:30:05 -0400, Alex Rønne Petersen
>>>> <xtzgzorex@gmail.com> wrote:
>>>>
>>>>> Purity inference won't happen either way. Purity is part of your API
>>>>> and also meant to help you reason about your code. If the compiler
>>>>> just infers purity in a function and you later change the
>>>>> implementation so it's no longer pure, you break your users' code.
>>>>> Also, purity would no longer help you reason about your code if it's
>>>>> not explicit.
>>>>
>>>> It can be pure for the purposes of optimization without affecting code
>>>> whatsoever. Inferred purity can be marked separately from explicit
>>>> purity, and explicitly pure functions would not be allowed to call
>>>> implicitly pure functions.
>>>>
>>>> -Steve
>>>
>>> But that kind of inferred purity is something a compiler back end
>>> cares about, not something the language should have to care about at
>>> all. In practice, most compilers *do* analyze all functions for
>>> possible side-effects and use that information where applicable.
>>
>> It affects how callers code will be generated.
>>
>> If I have a function
>>
>> int foo(int x);
>>
>> and I have another function which calls foo like:
>>
>> int y = foo(x) + foo(x);
>>
>> Then the optimization is applied to whatever function this exists in. If
>> the source isn't available for foo, the compiler cannot make this
>> optimization.
>>
>> I have no idea if this is a back-end or front-end issue. I'm not a
>> compiler writer. But I do understand that the compiler needs extra
>> information in the signature to determine if it can make this  
>> optimization.
>>
>
> OK, point taken; didn't consider that. But in the first place, for  
> inference of purity to work, the source would have to be available.  
> Then, that inferred property has to be propagated somehow so that the  
> compiler can make use of it when linking to the code as a library...

That's exactly what storing the interface in the object file does.  You  
don't need the source because the object file contains the compiler's  
interpretation of the source, and any inferred properties it has  
discovered.

-Steve
May 07, 2012
Re: GSOC Linker project
On Monday, 7 May 2012 at 12:36:18 UTC, Roald Ribe wrote:
> If you are interested in getting results rather than 
> reinventing the wheel,
> I would advice you to have a look at the openwatcom.org wlink, 
> and the
> forked jwlink as a starting point. The linker is open source, 
> written in
> C and has user documentation (not source doc unfortunately).
>
> Roald

Thanks for the tip! :)
What level of reinventing the wheel are we talking about? Did you 
suggest i fork (j)wlink or somesuch, or that i take a look at how 
it's implemented instead of reinventing from scratch? :)
And does anyone know if wlink is able to link programs from dmd? 
I made a half-hearted attempt myself, but didn't manage to get it 
to work ;p

/Pierre
May 07, 2012
Re: GSOC Linker project
On Mon, May 7, 2012 at 8:42 AM, Steven Schveighoffer <schveiguy@yahoo.com>wrote:

> On Mon, 07 May 2012 09:27:32 -0400, Alex Rønne Petersen <
> xtzgzorex@gmail.com> wrote:
>
>  On 07-05-2012 14:50, Steven Schveighoffer wrote:
>>
>>> On Mon, 07 May 2012 07:41:43 -0400, Alex Rønne Petersen
>>> <xtzgzorex@gmail.com> wrote:
>>>
>>>  On 07-05-2012 13:21, Steven Schveighoffer wrote:
>>>>
>>>>> On Fri, 04 May 2012 20:30:05 -0400, Alex Rønne Petersen
>>>>> <xtzgzorex@gmail.com> wrote:
>>>>>
>>>>>  Purity inference won't happen either way. Purity is part of your API
>>>>>> and also meant to help you reason about your code. If the compiler
>>>>>> just infers purity in a function and you later change the
>>>>>> implementation so it's no longer pure, you break your users' code.
>>>>>> Also, purity would no longer help you reason about your code if it's
>>>>>> not explicit.
>>>>>>
>>>>>
>>>>> It can be pure for the purposes of optimization without affecting code
>>>>> whatsoever. Inferred purity can be marked separately from explicit
>>>>> purity, and explicitly pure functions would not be allowed to call
>>>>> implicitly pure functions.
>>>>>
>>>>> -Steve
>>>>>
>>>>
>>>> But that kind of inferred purity is something a compiler back end
>>>> cares about, not something the language should have to care about at
>>>> all. In practice, most compilers *do* analyze all functions for
>>>> possible side-effects and use that information where applicable.
>>>>
>>>
>>> It affects how callers code will be generated.
>>>
>>> If I have a function
>>>
>>> int foo(int x);
>>>
>>> and I have another function which calls foo like:
>>>
>>> int y = foo(x) + foo(x);
>>>
>>> Then the optimization is applied to whatever function this exists in. If
>>> the source isn't available for foo, the compiler cannot make this
>>> optimization.
>>>
>>> I have no idea if this is a back-end or front-end issue. I'm not a
>>> compiler writer. But I do understand that the compiler needs extra
>>> information in the signature to determine if it can make this
>>> optimization.
>>>
>>>
>> OK, point taken; didn't consider that. But in the first place, for
>> inference of purity to work, the source would have to be available. Then,
>> that inferred property has to be propagated somehow so that the compiler
>> can make use of it when linking to the code as a library...
>>
>
> That's exactly what storing the interface in the object file does.  You
> don't need the source because the object file contains the compiler's
> interpretation of the source, and any inferred properties it has discovered.
>

Putting inferred purity into an object file sounds like a bad idea. It's
not hard to imagine this scenario:
-function foo in libSomething is inferred as pure (but not declared pure by
the author)
-exeSomethingElse is compiled to use libSomething, and the compiler takes
advantage of purity optimizations when calling foo
-libSomething is recompiled and foo is no longer pure, and exeSomethingElse
silently breaks

Purity inference is fine for templates (because recompiling the library
won't change the generated template code in an executable that depends on
it), but in all other cases, the API needs to be exactly what the author
declared it to be, or strange things will happen.
May 07, 2012
Re: GSOC Linker project
On Mon, 07 May 2012 12:59:24 -0400, Andrew Wiley  
<wiley.andrew.j@gmail.com> wrote:

> On Mon, May 7, 2012 at 8:42 AM, Steven Schveighoffer  
> <schveiguy@yahoo.com>wrote:
>> On Mon, 07 May 2012 09:27:32 -0400, Alex Rønne Petersen <
>>
>> That's exactly what storing the interface in the object file does.  You
>> don't need the source because the object file contains the compiler's
>> interpretation of the source, and any inferred properties it has  
>> discovered.
>>
>
> Putting inferred purity into an object file sounds like a bad idea. It's
> not hard to imagine this scenario:
> -function foo in libSomething is inferred as pure (but not declared pure  
> by
> the author)
> -exeSomethingElse is compiled to use libSomething, and the compiler takes
> advantage of purity optimizations when calling foo
> -libSomething is recompiled and foo is no longer pure, and  
> exeSomethingElse
> silently breaks

no, it just doesn't link.

> Purity inference is fine for templates (because recompiling the library
> won't change the generated template code in an executable that depends on
> it), but in all other cases, the API needs to be exactly what the author
> declared it to be, or strange things will happen.

I agree that's the case with the current object/linker model.  Something  
that puts inferred properties into the object file needs a new model, one  
which does not blindly link code that wasn't compiled from the same  
sources.

-Steve
May 07, 2012
Re: GSOC Linker project
Am 07.05.2012 15:30, schrieb Steven Schveighoffer:
> On Mon, 07 May 2012 09:22:05 -0400, Paulo Pinto <pjmlp@progtools.org>
> wrote:
>
>> This just confirms what I saw yesterday on a presentation.
>>
>> Many developers re-invent the wheel, or jump to the fad technology of the
>> year, because they don't have the knowledge of old already proven
>> technologies,
>> that for whatever reason, are no longer common.
>>
>> We need better ways to preserve knowledge in our industry.
>
> Again, don't take offense. I never suggested Java's use of an already
> existing technology was in some way a "new" thing, just that it proves
> it can work.
>
> I'm sure back in the day, TurboPascal had to walk uphill through the
> snow to school both ways too. :)
>
> -Steve


No offense taken.

My reply was just a small rant, based on your answer on lack of contact
with Turbo Pascal and other languages I mentioned.

Yesterday I watched a presentation, where the guy complains on knowledge
being lost due to the lack of proper mentors in the industry,

http://www.infoq.com/presentations/The-Frustrated-Architect

I have spent a huge time in the university learning about compiler
development, reading old books and papers from the early computing days.

So in a general way, and not directed to you now, I saddens me that a 
great part of that knowledge is lost to most youth nowadays.

Developers get amazed with JavaScript JIT compilation, and yet it 
already existed in Smalltalk systems.

Go advertises fast compilation speeds, and they were already available
to some language systems in the late 70's, early 80's.

We are discussing storing module interfaces directly in the library 
files, and most seem to never heard of it.

And the list goes on.

Sometimes I wonder what do students learn in modern CS courses.

--
Paulo
May 07, 2012
Re: GSOC Linker project
On Mon, May 7, 2012 at 12:21 PM, Steven Schveighoffer
<schveiguy@yahoo.com>wrote:

> On Mon, 07 May 2012 12:59:24 -0400, Andrew Wiley <wiley.andrew.j@gmail.com>
> wrote:
>
>  On Mon, May 7, 2012 at 8:42 AM, Steven Schveighoffer <schveiguy@yahoo.com
>> >wrote:
>>
>>> On Mon, 07 May 2012 09:27:32 -0400, Alex Rønne Petersen <
>>>
>>> That's exactly what storing the interface in the object file does.  You
>>> don't need the source because the object file contains the compiler's
>>> interpretation of the source, and any inferred properties it has
>>> discovered.
>>>
>>>
>> Putting inferred purity into an object file sounds like a bad idea. It's
>> not hard to imagine this scenario:
>> -function foo in libSomething is inferred as pure (but not declared pure
>> by
>> the author)
>> -exeSomethingElse is compiled to use libSomething, and the compiler takes
>> advantage of purity optimizations when calling foo
>> -libSomething is recompiled and foo is no longer pure, and
>> exeSomethingElse
>> silently breaks
>>
>
> no, it just doesn't link.
>
>
>  Purity inference is fine for templates (because recompiling the library
>> won't change the generated template code in an executable that depends on
>> it), but in all other cases, the API needs to be exactly what the author
>> declared it to be, or strange things will happen.
>>
>
> I agree that's the case with the current object/linker model.  Something
> that puts inferred properties into the object file needs a new model, one
> which does not blindly link code that wasn't compiled from the same sources.
>

Then all you've done is to make attributes the author can't control part of
the API, which will force library users to recompile their code more often
for non-obvious reasons. Avoiding that is one of the points of shared
libraries.

I think we're actually talking about different contexts. I'm speaking in
the context of shared libraries, where I think the API needs to be exactly
what the author requests and nothing more. With object files, static
libraries, and static linking, I agree that this sort of thing could work
and wouldn't cause the same problems because it's impossible to swap the
library code without recompiling/relinking the entire program.
3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home