Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #2039 > unrolled thread

Language standards vs. implementation, was Re: A right alternative to IEEE-754's format

Back to article view | Back to comp.compilers

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Language standards vs. implementation, was Re: A right alternative to IEEE-754's format "Walter Banks" <walter@bytecraft.com> - 2018-04-10 11:05 -0400
    Re: Language standards vs. implementation, was Re: A right alternative to IEEE-754's format bartc <bc@freeuk.com> - 2018-04-12 12:15 +0100

#2039 — Language standards vs. implementation, was Re: A right alternative to IEEE-754's format

 [[ this string is copied from comp.arch because your moderation found it interesting ]]

On 2018-04-09 7:48 AM, David Brown wrote:
> On 09/04/18 13:30, Walter Banks wrote:

>>
>> GCC tools are for the most part using old compiler technology.
>> Some of is decades old.
>
> You are fond of saying that, but I don't remember hearing any
> details or examples.
>

- Strategy passes to determine how an applications should be compiled
this time.

- Direct compiling to machine code and not using intermediate assembler
to get away from the two copy problem with code generation ISA restrictions.

- Whole application building. Why is linking still being done when its
purpose was to get around computer limitations?

w..

[toc] | [next] | [standalone]

#2064

On 10/04/2018 16:05, Walter Banks wrote:
>> On 09/04/18 13:30, Walter Banks wrote:

>>> GCC tools are for the most part using old compiler technology.
>>> Some of is decades old.
>>
>> You are fond of saying that, but I don't remember hearing any
>> details or examples.
>>
>
> - Strategy passes to determine how an applications should be compiled
> this time.
>
> - Direct compiling to machine code and not using intermediate assembler


> - Whole application building. Why is linking still being done when its
> purpose was to get around computer limitations?

Whole project compiling? I have a whole project compiler for one
language, and a half-completed one for another. Both need to be very
fast because they have to compile a whole application from scratch each
time (aiming for 0.1 secs build time per typical application).

But both languages have the features necessary to make that possible.

C doesn't; separate compilation and linking might still be the simplest
model for it.

Compilation speed is compromised anyway by needing to re-process header
files multiple times. (Precompiled headers aren't a solution because you
still have to process that precompiled header file; it might just be
faster than working with source code.)

I'm not saying it's not practical with C, but the language makes it harder.

(By 'whole project' I mean all the source modules that are normally
processed to end up with a single executable or shared library file.
External binary libraries stay external.)

--
bartc

[toc] | [prev] | [standalone]

Back to top | Article view | comp.compilers

csiph-web