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

Groups > comp.lang.c > #147711 > unrolled thread

curiosity about compiler phases

Back to article view | Back to comp.lang.c

Contents

  curiosity about compiler phases Thiago Adams <thiago.adams@gmail.com> - 2019-11-07 05:28 -0800
    Re: curiosity about compiler phases Nick Bowler <nbowler@draconx.ca> - 2019-11-22 19:25 +0000
    Re: curiosity about compiler phases "A. K." <minforth@arcor.de> - 2019-11-22 12:19 -0800
    Re: curiosity about compiler phases Bart <bc@freeuk.com> - 2019-11-22 22:22 +0000
      Typo? (Was: curiosity about compiler phases) gazelle@shell.xmission.com (Kenny McCormack) - 2019-11-22 22:34 +0000
        Re: Typo? (Was: curiosity about compiler phases) Bart <bc@freeuk.com> - 2019-11-22 23:49 +0000
          Re: Typo? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-11-22 19:26 -0700
      Re: curiosity about compiler phases scott@slp53.sl.home (Scott Lurndal) - 2019-11-22 23:12 +0000
        Re: curiosity about compiler phases Bart <bc@freeuk.com> - 2019-11-23 00:06 +0000
          Re: curiosity about compiler phases Richard Damon <Richard@Damon-Family.org> - 2019-11-22 20:34 -0500
          Re: curiosity about compiler phases Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-23 01:47 +0000
            Re: curiosity about compiler phases Richard Damon <Richard@Damon-Family.org> - 2019-11-22 21:21 -0500
              Re: curiosity about compiler phases Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-24 03:26 +0000
                Re: curiosity about compiler phases Bart <bc@freeuk.com> - 2019-11-24 11:29 +0000
                  Re: curiosity about compiler phases Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-24 16:49 +0000
            Re: curiosity about compiler phases Bart <bc@freeuk.com> - 2019-11-23 12:21 +0000
              Re: curiosity about compiler phases Richard Damon <Richard@Damon-Family.org> - 2019-11-23 10:08 -0500
              Re: curiosity about compiler phases scott@slp53.sl.home (Scott Lurndal) - 2019-11-23 15:49 +0000
                Re: curiosity about compiler phases Bart <bc@freeuk.com> - 2019-11-23 16:21 +0000
                  Re: curiosity about compiler phases Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-24 03:37 +0000
                    Re: curiosity about compiler phases Bart <bc@freeuk.com> - 2019-11-24 11:25 +0000
                      Re: curiosity about compiler phases Bart <bc@freeuk.com> - 2019-11-25 14:06 +0000
      Re: curiosity about compiler phases Keith Thompson <kst-u@mib.org> - 2019-11-22 21:25 -0800
        Beyond our pay grade (Was: curiosity about compiler phases) gazelle@shell.xmission.com (Kenny McCormack) - 2019-11-23 07:43 +0000
      Re: curiosity about compiler phases Thiago Adams <thiago.adams@gmail.com> - 2019-11-23 06:28 -0800
        Re: curiosity about compiler phases Thiago Adams <thiago.adams@gmail.com> - 2019-11-23 06:39 -0800
        Re: curiosity about compiler phases Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2019-11-23 09:46 -0500
          Re: curiosity about compiler phases Richard Damon <Richard@Damon-Family.org> - 2019-11-23 10:16 -0500
        Re: curiosity about compiler phases Bart <bc@freeuk.com> - 2019-11-23 16:13 +0000
          Re: curiosity about compiler phases Thiago Adams <thiago.adams@gmail.com> - 2019-11-25 03:24 -0800
    Re: curiosity about compiler phases Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-23 08:43 +0100

Page 2 of 2 — ← Prev page 1 [2]

#148148

On 24/11/2019 03:37, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> 
>> The one I used was gfortran compiled with gcc, running on
>> rextester.com so probably not Windows. This program didn't compile
>> (4-space indentation added):
>>
>>      !gfortran, gcc version 5.4.0 20160609
>>
>>      program hello
>>          pri&
>>      nt *, "Hello World!"
> 
> You need
> 
>        &nt *, "Hello World!"

OK, you need two &s, at the end of one line, and at the start of the next.

>        
>>      end program hello


>>
>> Probably, an older Fortran that is strictly column-based would work,
> 
> Yes it does.  That's the form I was talking about.

Don't forget that Fortran lexing is (or was) rather weird anyway, since 
the language ignores white space. So you could write:

     pr int* ,"hello"

Then, having an intervening break via line-splicing is less remarkable.

(rextester doesn't support this, and doesn't offer a way to add 
command-line options.)

[toc] | [prev] | [next] | [standalone]

#148158

On 24/11/2019 11:25, Bart wrote:
> On 24/11/2019 03:37, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> The one I used was gfortran compiled with gcc, running on
>>> rextester.com so probably not Windows. This program didn't compile
>>> (4-space indentation added):
>>>
>>>      !gfortran, gcc version 5.4.0 20160609
>>>
>>>      program hello
>>>          pri&
>>>      nt *, "Hello World!"
>>
>> You need
>>
>>        &nt *, "Hello World!"
> 
> OK, you need two &s, at the end of one line, and at the start of the next.

Actually, the behaviour is not consistent:

You only need one & at the end of the first line, to split between tokens.

You need two to split in the middle of a token.

If you want one or more empty lines between the first and second, each 
of those lines needs && (other white space on the line ignored, but in 
other contexts and before the first/only &, an after the &, is significant).

So the behaviour is rather complex with rules that are likely to be 
different from other languages' line continuation schemes.

Note that while this language doesn't need special statement endings 
such as ";", where a line ends with "," (or other symbols suggesting 
continuation such as "("), the line doesn't automatically continue onto 
the next.

So it NEEDS the line continuation more than many others where such 
common cases don't need any special indications.

AFAICS it is something that can be dropped from C, except from the 
line-based preprocessor where it only appears to be needed inside macro 
definitions.

[toc] | [prev] | [next] | [standalone]

#148134

Bart <bc@freeuk.com> writes:
[...]
> Every so often you come across crazy things that C allows in its 
> preprocessor; this is one of them. Not just being able to split up lines 
> between tokens, but even in the middle of tokens!

What you call crazy, I call simple.

Backslash-newline sequences are spliced in translation phase 2.
Preprocessing tokens aren't recognized until phase 3 (and
preprocessing tokens aren't converted into tokens until phase 7).
Of course a compiler isn't required to implement the 8 translation
phases explicitly, but a conforming compiler must behave as if
it did.

You've simply discovered another way in which it's possible to do
ugly things in C.  There is no language in which it isn't possible
to do ugly things.

"Doctor, my code is ugly when I do this!"

If your C compiler doesn't implement this as the standard requires,
then there could be standard-conforming C code that your compiler
can't handle.  To be clear, that doesn't bother me.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#148135 — Beyond our pay grade (Was: curiosity about compiler phases)

In article <ln8so7xiz7.fsf@kst-u.example.com>,
Keith Thompson  <kst-u@mib.org> wrote:
>Bart <bc@freeuk.com> writes:
>[...]
>> Every so often you come across crazy things that C allows in its 
>> preprocessor; this is one of them. Not just being able to split up lines 
>> between tokens, but even in the middle of tokens!
>
>What you call crazy, I call simple.

There is quite often a fine line between mental illness and mental deficiency.

Being as we're all just computer programmers here, it is unlikely we have
the skills or the qualifications to make the call.  In this case or any
other.

-- 
In the corner of the room on the ceiling is a large vampire bat who
is obviously deranged and holding his nose.

[toc] | [prev] | [next] | [standalone]

#148138

On Friday, November 22, 2019 at 7:22:39 PM UTC-3, Bart wrote:
> On 07/11/2019 13:28, Thiago Adams wrote:
> > I am doing some review in my lexer and I found the following
> > curiosity when I was experimenting compiler explorer online.
> > 
> > When I print the preprocessor output -E of this code:
> > 
> > in\
> > t i =09;
> > 
> > using x86-64 gcc 4.4.7, it prints:
> > int i =09;
> > 
> > using x86-64 gcc 4.6.4, it prints:
> > int
> >    i =09;
> 
> Every so often you come across crazy things that C allows in its 
> preprocessor; this is one of them. Not just being able to split up lines 
> between tokens, but even in the middle of tokens!
> 
> So you could in theory write C programs one character per line, or write 
> numbers like this:
> 
>    a = 1\
> 000\
> 000;
> 
> giving it numeric separators. Another one is being able to use macros as 
> part of #include lines. But the way it does that is staggeringly crass:
> 
>   #define STAT  <sys/stat.h>
>   #include STAT
> 
> This works (some compilers allow spaces around / etc), but is done by 
> concatenating tokens "sys", "/", "stat", "." and "h". Here:
> 
>   #include FILE <A123.456.789>
>   #include FILE
> 
> The filename is formed (with bcc anyway) with the three tokens A123, 
> .456 and .789, the last two floating point constants.
> 
> 
> With the line continuation in the middle of tokens, I simply took the 
> decision that is was too ridiculous to implement. The fewer compilers 
> that pander to it, the less likely it is that any programs will come to 
> depend on it.

In my transpiler this is another item that makes live difficult.
I have implemented in the wrong phase and I will fix this someday.

I guess at some point they c standard realized that this can be 
implemented at early phase and just make it work everywhere.

I believe that at time they were not thinking about refactoring tools
and how this could just make these tools harder to write in the future.

[toc] | [prev] | [next] | [standalone]

#148139

On Saturday, November 23, 2019 at 11:28:31 AM UTC-3, Thiago Adams wrote:
.. 
> I believe that at time they were not thinking about refactoring tools
> and how this could just make these tools harder to write in the future.

int main()
{
    int i\
a = 1;

    ia = 2;
}
Visual Studio has a rename tool. I  tried to rename ia variable
to ib. It din't changed the 'i\a'.

[toc] | [prev] | [next] | [standalone]

#148140

Thiago Adams wrote:

> On Friday, November 22, 2019 at 7:22:39 PM UTC-3, Bart wrote:
>> On 07/11/2019 13:28, Thiago Adams wrote:
[snip]
>> Every so often you come across crazy things that C allows in its
>> preprocessor; this is one of them. Not just being able to split up lines
>> between tokens, but even in the middle of tokens!
[snip]
> I guess at some point they c standard realized that this can be
> implemented at early phase and just make it work everywhere.

> I believe that at time they were not thinking about refactoring tools
> and how this could just make these tools harder to write in the future.

You've got it backwards. Your comment is, to me, much like blaming the horse 
for not being big enough for the saddle you bought. 

The authors of the "refactoring tools" are at fault here for not accounting 
for C line splicing as permitted in the C standard.

-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#148142

On 11/23/19 9:46 AM, Lew Pitcher wrote:
> Thiago Adams wrote:
> 
>> On Friday, November 22, 2019 at 7:22:39 PM UTC-3, Bart wrote:
>>> On 07/11/2019 13:28, Thiago Adams wrote:
> [snip]
>>> Every so often you come across crazy things that C allows in its
>>> preprocessor; this is one of them. Not just being able to split up lines
>>> between tokens, but even in the middle of tokens!
> [snip]
>> I guess at some point they c standard realized that this can be
>> implemented at early phase and just make it work everywhere.
> 
>> I believe that at time they were not thinking about refactoring tools
>> and how this could just make these tools harder to write in the future.
> 
> You've got it backwards. Your comment is, to me, much like blaming the horse 
> for not being big enough for the saddle you bought. 
> 
> The authors of the "refactoring tools" are at fault here for not accounting 
> for C line splicing as permitted in the C standard.
> 

Or they just need to document their limitations.

It is perfectly fine to document that your refactoring tool makes
certain assumptions about the code, and in fact it almost has to.

For instance, I have a function called int_print that I want to rename
to integer_print

In the code is the fragment

#define TYPE int

/* many lines of code, maybe even in an include and then we reach */

  TYPE##_print

What does the refactoring tool do? What CAN it do?

[toc] | [prev] | [next] | [standalone]

#148144

On 23/11/2019 14:28, Thiago Adams wrote:
> On Friday, November 22, 2019 at 7:22:39 PM UTC-3, Bart wrote:

>> With the line continuation in the middle of tokens, I simply took the
>> decision that is was too ridiculous to implement. The fewer compilers
>> that pander to it, the less likely it is that any programs will come to
>> depend on it.
> 
> In my transpiler this is another item that makes live difficult.
> I have implemented in the wrong phase and I will fix this someday.

You could just add a line-splicing pass as I mentioned, such as the 
following function, which takes an entire, just-loaded source file 
represented as one string, and returns another string:

   char* splicelines(char * s) {
       char *t,*u;

       t = u = malloc(strlen(s)+1);
       if (t == NULL) return NULL;

       while (*s) {
           if (*s == '\\' && *(s+1) == 10) s += 2;
           else if (*s == '\\' && *(s+1) == 13 && *(s+2) == 10) s += 3;
           else *t++ = *s++;
       }
       *t = 0;

       return u;
   }


If I write a version of this for my compiler, and add these lines just 
after a source file has been loaded:

     if dolinesplicing then
         s := splicelines(s)     # (uses different allocation call)
     fi

then it will compile the examples I posted. But I won't keep it, as I 
think it is largely a waste of time. This was just to show I can support 
the feature if I have to. (It also slows down compilation but by 3-12% 
depending on how it is built.)

[toc] | [prev] | [next] | [standalone]

#148155

On Saturday, November 23, 2019 at 1:13:35 PM UTC-3, Bart wrote:
> On 23/11/2019 14:28, Thiago Adams wrote:
> > On Friday, November 22, 2019 at 7:22:39 PM UTC-3, Bart wrote:
> 
> >> With the line continuation in the middle of tokens, I simply took the
> >> decision that is was too ridiculous to implement. The fewer compilers
> >> that pander to it, the less likely it is that any programs will come to
> >> depend on it.
> > 
> > In my transpiler this is another item that makes live difficult.
> > I have implemented in the wrong phase and I will fix this someday.
> 
> You could just add a line-splicing pass as I mentioned, such as the 
> following function, which takes an entire, just-loaded source file 
> represented as one string, and returns another string:


In my transpiler, I also keep the original code format,
then I can use the same tool for refactoring and for a kind
of assistant working at the same file.

The way I will do, is to preserve the line splitting inside
tokens.

For instance, an 'int' can be splitted 'int\\nt'. Generally the
lexeme is not used because the token id (enum) is used instead.

The problem is for identifiers, in this case I will need to use 
a special strcmp function that 
ignores the split and this can have a small effect on performance.

[toc] | [prev] | [next] | [standalone]

#148136

For what are this Nerd-experiments good for?

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web