The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* Re: [TUHS] Archaic yacc C grammar
@ 2018-10-31 15:39 Noel Chiappa
  0 siblings, 0 replies; 14+ messages in thread
From: Noel Chiappa @ 2018-10-31 15:39 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Steve Johnson

    > references that were checked using the pointer type of the structure
    > pointer. My code was a nightmare, and some of the old Unix code was at
    > least a bad dream.

I had a 'fun' experience with this when I went to do the pipe splice() system
call (after the discussion here). I elected to do it in V6, which I i) had
running, and ii) know like the back of my hand.

Alas! V6 uses 'int *' everywhere for pointers to structures. It also, in the
pipe code, uses constructs like '(p+1)' to provide wait channels. When I wrote
the new code, I naturally declared my pointers as 'struct inode *ip', or
whatever. However, when I went to do 'sleep(ip+1)', the wrong thing happened!
And since V6 C didn't have coercions, I couldn't win that way. IIRC, I finally
resorted to declaring an 'int *xip', and doing an 'xip = ip' before finally
doing my 'sleep(xip+1)'. Gack!

	  Noel

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [TUHS] Archaic yacc C grammar
  2018-10-31  0:58           ` Larry McVoy
  2018-10-31 13:49             ` Clem Cole
@ 2018-11-03 22:14             ` Steve Johnson
  1 sibling, 0 replies; 14+ messages in thread
From: Steve Johnson @ 2018-11-03 22:14 UTC (permalink / raw)
  To: Larry McVoy, Steve Johnson; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 2212 bytes --]



    ----- Original Message -----
    From:"Larry McVoy" <lm@mcvoy.com>

    ...
     I get that it doesn't scale but man, oh man, do I love the
early Unix
    data structures that had one namespace. I kinda wish you hadn't
fixed
    that Steve.

What was the push that made you fix it?

It came from Dennis, so I can't say why he decided to change it.  The
argument for it is that many structures would have similar names and
similar functions, such as "next" and "prev" in linked lists.  
Adding a new linked list action could be done much more easily by
copying the code and changing the declaration, instead of having to
change ab_next into cd_next, and then dealing with the inevitable
typos that would sneak a use of ab_next into code for cd.

Just to clarify, from the beginning I considered C to be Dennis'
language.  I would make suggestions, and sometimes he adopted them
(I'm responsible for ^ as the exclusive OR, for example).  In one
case, with casts, we were porting Unix to the 32-bit Interdata and
desparately needed a cast operator, but couldn't find a syntax that we
liked that was general enough to handle casts to, for example,
structure pointers or function pointers.  Matters were approaching a
crisis, and one evening I played with the yacc grammar and worked out
the strengths and weaknesses of the top three candidates.  I
suggested the one that I felt was best, and that was what was adopted.
  The simple rule was that you formed a cast by taking a declaration
of what you wanted the result to be, remove the variable being
declared, and enclose the rest in parens.  I had implemented it and
saw that it worked (because the port was based on PCC, there wasn't
nearly the pressure to change the PDP-11 compiler).   The fact that
we could explain the syntax in one sentence led us to feel like it
would be reasonable.   The problem, of course, is that we didn't put
anything back where the variable had been, so when you encounter a
nontrivial cast you have to enumerate all the possible places a
variable might be and determine which one is syntactically correst
while your brain turns to mush... 

Steve



[-- Attachment #2: Type: text/html, Size: 2612 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [TUHS] Archaic yacc C grammar
  2018-10-30  8:16         ` Lars Brinkhoff
@ 2018-11-03 21:50           ` Steve Johnson
  0 siblings, 0 replies; 14+ messages in thread
From: Steve Johnson @ 2018-11-03 21:50 UTC (permalink / raw)
  To: Lars Brinkhoff, Warner Losh; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]


One thing that was supported on PCC for many years was the ability to
generate GE/Honeywell 6-bit character constants, using the back quote
(`) character.  I remember trying it in the late 80's on a shipping
Sun machine and seeing that it was still present in the grammar, and,
as nearly as I could remember, still produced the correct answer.

Steve

----- Original Message -----
From: "Lars Brinkhoff" <lars@nocrew.org>
To:"Warner Losh" <imp@bsdimp.com>
Cc:"Steve Johnson" <scj@yaccman.com>, "The Eunuchs Hysterical Society"
<tuhs@tuhs.org>
Sent:Tue, 30 Oct 2018 08:16:17 +0000
Subject:Re: [TUHS] Archaic yacc C grammar

 Warner Losh wrote:
 > Steve Johnson wrote:
 > We actually had a pretty good system for making changes like
 > that. First, we would change the compiler to accept both the old
and
 > the new. Then we would produce a warning that on a particular date
 > the old would no longer work. Then we made the old an error and
 > printed a message about how to fix it.
 >
 > How long a transition period did you typically have?

 I heard the V7 compiler still supports old B style initialization
 "int x 42;". So in some cases, a really long time.



[-- Attachment #2: Type: text/html, Size: 1939 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [TUHS] Archaic yacc C grammar
  2018-10-31  0:58           ` Larry McVoy
@ 2018-10-31 13:49             ` Clem Cole
  2018-11-03 22:14             ` Steve Johnson
  1 sibling, 0 replies; 14+ messages in thread
From: Clem Cole @ 2018-10-31 13:49 UTC (permalink / raw)
  To: Larry McVoy; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

On Tue, Oct 30, 2018 at 9:46 PM Larry McVoy <lm@mcvoy.com> wrote:

> Instead of
>
>         p->size
>
> we have
>
>         p->st_size
>
> and I instantly know that p is a struct stat pointer.
>
+1
Amen Larry.   I understand why people had a desire for different
namespaces, but a single namespace sure made code a lot more readable and
understandable.
I still use that trick in new code, because I think it just makes it easier
to identify what is going on when I glance at it.

Clem

ᐧ

[-- Attachment #2: Type: text/html, Size: 1830 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [TUHS] Archaic yacc C grammar
  2018-10-30 22:01         ` Steve Johnson
  2018-10-31  0:58           ` Larry McVoy
@ 2018-10-31  6:09           ` Lars Brinkhoff
  1 sibling, 0 replies; 14+ messages in thread
From: Lars Brinkhoff @ 2018-10-31  6:09 UTC (permalink / raw)
  To: Steve Johnson; +Cc: The Eunuchs Hysterical Society

Steve Johnson wrote:
> The closest I came was when we went from a single namespace for all
> structure names to a namespace for each structure, and references that
> were checked using the pointer type of the structure pointer.  My code
> was a nightmare, and some of the old Unix code was at least a bad
> dream.

How about this, pointer to int used as pointer to struct.

prlook( pp ) int *pp;{
        int j;
        pp = pp->lset;
....

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [TUHS] Archaic yacc C grammar
  2018-10-30 22:01         ` Steve Johnson
@ 2018-10-31  0:58           ` Larry McVoy
  2018-10-31 13:49             ` Clem Cole
  2018-11-03 22:14             ` Steve Johnson
  2018-10-31  6:09           ` Lars Brinkhoff
  1 sibling, 2 replies; 14+ messages in thread
From: Larry McVoy @ 2018-10-31  0:58 UTC (permalink / raw)
  To: Steve Johnson; +Cc: The Eunuchs Hysterical Society

I'm coming into this late (and tired, been working on my water system
and the carbs on my boat all day) but I *loved* the single namespace
for all structure fields.

Instead of 

	p->size

we have

	p->st_size

and I instantly know that p is a struct stat pointer.  

I get that it doesn't scale but man, oh man, do I love the early Unix
data structures that had one namespace.  I kinda wish you hadn't fixed
that Steve.

What was the push that made you fix it?

On Tue, Oct 30, 2018 at 03:01:55PM -0700, Steve Johnson wrote:
> The closest I came was when we went from a single namespace for all
> structure names to a namespace for each structure, and references that
> were checked using the pointer type of the structure pointer.
> My code was a nightmare, and some of the old Unix code was at least a
> bad dream.???? I had to start out pretending to have a single
> namespace, but when I saw the use of an actual structure pointer I had
> 
> 
> to do it the new way.?? As I recall when I saw something that would
> not have been legal with the old rules (for example, two different
> structures with the same element name but different offsets) then I
> threw
>  the switch and demanded the new way.?? 
> 
> There were certainly system changes that were flash cut.?? For
> example, changing the file system format -- there was no attempt to
> allow both, which meant that the conversion program got one shot to
> get it right.?? And it didn't always manage that...
> 
> Steve
> 
> ----- Original Message -----
> From:
>  david@kdbarto.org
> 
> To:
> "Steve Johnson" <scj@yaccman.com>
> Cc:
> "The Eunuchs Hysterical Society" <tuhs@tuhs.org>
> Sent:
> Mon, 29 Oct 2018 12:02:29 -0700
> Subject:
> Re: [TUHS] Archaic yacc C grammar
> 
> On Oct 29, 2018, at 10:52 AM, Steve Johnson <scj@yaccman.com [1]>
> wrote:
> 
> We actually had a pretty good system for making changes like that.??
> First, we would change
> the compiler to accept both the old and the new.???? Then we would
> produce a warning
> that on a particular date the old would no longer work.?? Then we made
> the old an error
> and printed a message about how to fix it.???? Eventually, we just let
> it be a syntax error.
> This process was applied many times on the way from typeless B to
> strongly typed C.
> 
> Was there ever a time when a change was desired that you couldn???t
> accept both
> the old and the new?
> 
> David
> 
>  
> 
> Links:
> ------
> [1] mailto:scj@yaccman.com
> 

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [TUHS] Archaic yacc C grammar
  2018-10-29 19:02       ` David
@ 2018-10-30 22:01         ` Steve Johnson
  2018-10-31  0:58           ` Larry McVoy
  2018-10-31  6:09           ` Lars Brinkhoff
  0 siblings, 2 replies; 14+ messages in thread
From: Steve Johnson @ 2018-10-30 22:01 UTC (permalink / raw)
  To: david, Steve Johnson; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1875 bytes --]

The closest I came was when we went from a single namespace for all
structure names to a namespace for each structure, and references that
were checked using the pointer type of the structure pointer.
My code was a nightmare, and some of the old Unix code was at least a
bad dream.   I had to start out pretending to have a single
namespace, but when I saw the use of an actual structure pointer I had


to do it the new way.  As I recall when I saw something that would
not have been legal with the old rules (for example, two different
structures with the same element name but different offsets) then I
threw
 the switch and demanded the new way.  

There were certainly system changes that were flash cut.  For
example, changing the file system format -- there was no attempt to
allow both, which meant that the conversion program got one shot to
get it right.  And it didn't always manage that...

Steve

----- Original Message -----
From:
 david@kdbarto.org

To:
"Steve Johnson" <scj@yaccman.com>
Cc:
"The Eunuchs Hysterical Society" <tuhs@tuhs.org>
Sent:
Mon, 29 Oct 2018 12:02:29 -0700
Subject:
Re: [TUHS] Archaic yacc C grammar

On Oct 29, 2018, at 10:52 AM, Steve Johnson <scj@yaccman.com [1]>
wrote:

We actually had a pretty good system for making changes like that. 
First, we would change
the compiler to accept both the old and the new.   Then we would
produce a warning
that on a particular date the old would no longer work.  Then we made
the old an error
and printed a message about how to fix it.   Eventually, we just let
it be a syntax error.
This process was applied many times on the way from typeless B to
strongly typed C.

Was there ever a time when a change was desired that you couldn’t
accept both
the old and the new?

David

 

Links:
------
[1] mailto:scj@yaccman.com


[-- Attachment #2: Type: text/html, Size: 2876 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [TUHS] Archaic yacc C grammar
  2018-10-29 18:37       ` Warner Losh
@ 2018-10-30  8:16         ` Lars Brinkhoff
  2018-11-03 21:50           ` Steve Johnson
  0 siblings, 1 reply; 14+ messages in thread
From: Lars Brinkhoff @ 2018-10-30  8:16 UTC (permalink / raw)
  To: Warner Losh; +Cc: The Eunuchs Hysterical Society

Warner Losh wrote:
> Steve Johnson wrote:
>  We actually had a pretty good system for making changes like
>  that. First, we would change the compiler to accept both the old and
>  the new. Then we would produce a warning that on a particular date
>  the old would no longer work. Then we made the old an error and
>  printed a message about how to fix it.
>
> How long a transition period did you typically have?

I heard the V7 compiler still supports old B style initialization
"int x 42;".  So in some cases, a really long time.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [TUHS] Archaic yacc C grammar
  2018-10-29 17:52     ` Steve Johnson
  2018-10-29 18:37       ` Warner Losh
@ 2018-10-29 19:02       ` David
  2018-10-30 22:01         ` Steve Johnson
  1 sibling, 1 reply; 14+ messages in thread
From: David @ 2018-10-29 19:02 UTC (permalink / raw)
  To: Steve Johnson; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]


> On Oct 29, 2018, at 10:52 AM, Steve Johnson <scj@yaccman.com> wrote:
> 
> We actually had a pretty good system for making changes like that.  First, we would change
> the compiler to accept both the old and the new.   Then we would produce a warning
> that on a particular date the old would no longer work.  Then we made the old an error
> and printed a message about how to fix it.   Eventually, we just let it be a syntax error.
> This process was applied many times on the way from typeless B to strongly typed C.

Was there ever a time when a change was desired that you couldn’t accept both
the old and the new?

	David


[-- Attachment #2: Type: text/html, Size: 1397 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [TUHS] Archaic yacc C grammar
  2018-10-29 17:52     ` Steve Johnson
@ 2018-10-29 18:37       ` Warner Losh
  2018-10-30  8:16         ` Lars Brinkhoff
  2018-10-29 19:02       ` David
  1 sibling, 1 reply; 14+ messages in thread
From: Warner Losh @ 2018-10-29 18:37 UTC (permalink / raw)
  To: Steve Johnson; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 593 bytes --]

On Mon, Oct 29, 2018 at 12:30 PM Steve Johnson <scj@yaccman.com> wrote:

> We actually had a pretty good system for making changes like that.  First,
> we would change
> the compiler to accept both the old and the new.   Then we would produce a
> warning
> that on a particular date the old would no longer work.  Then we made the
> old an error
> and printed a message about how to fix it.   Eventually, we just let it be
> a syntax error.
> This process was applied many times on the way from typeless B to strongly
> typed C.
>

How long a transition period did you typically have?

Warner

[-- Attachment #2: Type: text/html, Size: 997 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [TUHS] Archaic yacc C grammar
  2018-10-29  7:31   ` Lars Brinkhoff
@ 2018-10-29 17:52     ` Steve Johnson
  2018-10-29 18:37       ` Warner Losh
  2018-10-29 19:02       ` David
  0 siblings, 2 replies; 14+ messages in thread
From: Steve Johnson @ 2018-10-29 17:52 UTC (permalink / raw)
  To: Lars Brinkhoff, Steve Johnson; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]


Yes.  If it was =op, this means the C program probably used =+
instead of +=.  That was the
dialect of C that was around when Al was at Bell Labs.  The
transition from =+ to += was a
pain, but decreased errors dramatically (a=-1 vs a= -1).

We actually had a pretty good system for making changes like that. 
First, we would change
the compiler to accept both the old and the new.   Then we would
produce a warning
that on a particular date the old would no longer work.  Then we made
the old an error
and printed a message about how to fix it.   Eventually, we just let
it be a syntax error.
This process was applied many times on the way from typeless B to
strongly typed C.

----- Original Message -----
From: "Lars Brinkhoff" <lars@nocrew.org>
To:"Steve Johnson" <scj@yaccman.com>
Cc:<tuhs@tuhs.org>
Sent:Mon, 29 Oct 2018 07:31:24 +0000
Subject:Re: [TUHS] Archaic yacc C grammar

 Steve Johnson wrote:
 > Looking at the reserved words, there is one, ENTRY, that I've never
 > heard of (although FORTRAN had an ENTRY statement), and there is
 > STRUCT but no UNION. Also, he uses val= instead of $$=. There don't
 > seem to be any nontrivial assignment ops (neither += or =+).

 This is for Snyder's C compiler. There is something called =op which
 is guess is for =+ etc.

 > I'm guessing either Al wrote it from scratch or based it on some
other
 > similar program.

 Looks like you're right. I found this in another file, so it would
seem
 he wrote it back at MIT:

 "The original YACC was designed and implemented on a PDP-11/45 and a
 Honeywell 6000 by S. C. Johnson at Bell Laboratories. The version
 described in this paper was implemented on the PDP-10 by Alan Snyder.


[-- Attachment #2: Type: text/html, Size: 2534 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [TUHS] Archaic yacc C grammar
  2018-10-29  3:00 ` Steve Johnson
@ 2018-10-29  7:31   ` Lars Brinkhoff
  2018-10-29 17:52     ` Steve Johnson
  0 siblings, 1 reply; 14+ messages in thread
From: Lars Brinkhoff @ 2018-10-29  7:31 UTC (permalink / raw)
  To: Steve Johnson; +Cc: tuhs

Steve Johnson wrote:
> Looking at the reserved words, there is one, ENTRY, that I've never
> heard of (although FORTRAN had an ENTRY statement), and there is
> STRUCT but no UNION. Also, he uses val= instead of $$=. There don't
> seem to be any nontrivial assignment ops (neither += or =+).

This is for Snyder's C compiler.  There is something called =op which
is guess is for =+ etc.

> I'm guessing either Al wrote it from scratch or based it on some other
> similar program.

Looks like you're right.  I found this in another file, so it would seem
he wrote it back at MIT:

  "The original YACC was designed and implemented on a PDP-11/45 and a
  Honeywell 6000 by S. C. Johnson at Bell Laboratories.  The version
  described in this paper was implemented on the PDP-10 by Alan Snyder.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [TUHS] Archaic yacc C grammar
  2018-10-28 21:34 Lars Brinkhoff
@ 2018-10-29  3:00 ` Steve Johnson
  2018-10-29  7:31   ` Lars Brinkhoff
  0 siblings, 1 reply; 14+ messages in thread
From: Steve Johnson @ 2018-10-29  3:00 UTC (permalink / raw)
  To: Lars Brinkhoff, tuhs

[-- Attachment #1: Type: text/plain, Size: 12516 bytes --]


I don't recognize this as any Yacc that my hands have touched.   
Looking at the reserved words,
there is one, ENTRY, that I've never heard of (although FORTRAN had an
ENTRY statement), 

and there is STRUCT but no UNION.  Also, he uses val= instead of
$$=.  There don't seem to be 

any nontrivial assignment ops (neither += or =+).

Al was at Bell Labs in 1973, and this is dated 5 years later.

The use of quotes for single character literals was in early Yaccs,
but it led to some strange-looking 

lexical analyzer code, and I quickly gave it up.

I'm guessing either Al wrote it from scratch or based it on some other
similar program.  LR parsing
made quite a stir in the 70's.

Can't help you though as far as how to generate a parser from this
input...

Steve

----- Original Message -----
From: "Lars Brinkhoff" <lars@nocrew.org>
To:<tuhs@tuhs.org>
Cc:
Sent:Sun, 28 Oct 2018 21:34:49 +0000
Subject:[TUHS] Archaic yacc C grammar

 Hello,

 This is Alan Snyder's C grammar. It's supposedly for yacc, but it's
 probably using some really ancient version. Maybe from when Alan did
a
 stint at Bell labs and converted yacc from B to C.

 Does anyone recognize this type of yacc input? I don't have the
 corresponding yacc version, and the one in V6 isn't happy about this
 file. What would it take to update the grammar for V6 yacc? Add in
 some %term, replace  with %%?

 # C GRAMMAR #
 # 28 May 1978 #
 # Alan Snyder #

 # 26 acceptable conflicts:

 2 S/R conflicts for (parsing) ambiguity between
 declarators and function_declarators
 1 S/R conflict for the C ELSE ambiguity
 4 R/R conflicts for the (parsing) problem with regard
 to integer constants as initial_values
 12 R/R conflicts for the (parsing) problem with regard
 to identifiers in function calls
 1 R/R conflict for the (parsing) problem with regard
 to identifiers in goto statements
 4 R/R conflicts and 1 S/R conflict for TYPEDEFs
 1 S/R conflict for ambiguous cast types
 (int ()) = (int x()) not (int (x))

 Approximate description:

 18 S/R ( shift 37 reduce 141
 50 S/R ( shift 37 reduce 71
 81 S/R ( shift 37 reduce 71
 113 R/R ( reduce 141 reduce 140
 113 R/R ( reduce 159 reduce 140
 113 R/R * reduce 159 reduce 141
 113 S/R : shift 199 reduce 141
 183 R/R , reduce 203 reduce 24
 183 R/R } reduce 203 reduce 24
 204 R/R ( reduce 159 reduce 140
 206 R/R ( reduce 148 reduce 139
 207 R/R ( reduce 147 reduce 139
 208 R/R ( reduce 145 reduce 139
 209 R/R ( reduce 144 reduce 139
 210 R/R ( reduce 146 reduce 139
 211 R/R ( reduce 149 reduce 139
 212 R/R ( reduce 150 reduce 139
 215 R/R ( reduce 159 reduce 140
 215 R/R ; reduce 159 reduce 138
 225 R/R ( reduce 151 reduce 139
 228 R/R ( reduce 159 reduce 140
 284 R/R , reduce 203 reduce 25
 284 R/R } reduce 203 reduce 25
 291 S/R ) shift 339 reduce 165
 343 R/R ( reduce 153 reduce 139
 360 S/R ELSE shift 369 reduce 94

 #

 # terminal symbols #

 ';' '}' '{' ']' '[' ')' '(' ':'
 ',' '.' '?' '~' '!' '&' '|' '^'
 '%' '/' '*' '-' '+' '=' '<' '>'
 '++' '--' '==' '!=' '<=' '>=' '<<' '>>'
 '->' '=op' '&&' '||' 'c'
 INT CHAR FLOAT DOUBLE STRUCT AUTO STATIC
 EXTERN RETURN GOTO IF ELSE SWITCH
 BREAK CONTINUE WHILE DO FOR DEFAULT CASE
 ENTRY REGISTER SIZEOF LONG SHORT UNSIGNED TYPEDEF 'l'
 'm' 'n' 'o' 'p' 'q' 'r' 's'
 identifier integer floatcon string

 # precedence information #

 < ','
 > '=' '=op'
 > '?' ':'
 < '||'
 < '&&'
 < '|'
 < '^'
 < '&'
 < '==' '!='
 < '<' '>' '<=' '>='
 < '<<' '>>'
 < '+' '-'
 < '*' '/' '%'
 > '!' '~'
 > '++' '--' SIZEOF
 < '[' '(' '.' '->'

 

 # external definitions #

 program:
 program external_definition
 |

 external_definition:
 declaration
 | function_definition

 function_definition:
 function_specification function_body {afdef(#1,#2);}

 function_specification:
 decl_specifiers function_declarator {val=afdcl(1);}
 | function_declarator {val=afdcl(0);}

 function_body:
 formal_declarations compound_statement {val=#2;}

 formal_declarations:
 formal_decl_list {afpdcl();}
 | {afpdcl();}

 compound_statement:
 begin declaration_list statement_list end {val=#3;}
 | begin statement_list end {val=#2;}

 init_declarator_list:
 init_declarator
 | init_declarator_list ',' init_declarator 

 init_declarator:
 $declarator initializer {aidecl();}
 | declarator {aidecl();}
 | function_declarator {adeclr(maktyp());}

 initializer:
 initial_value
 | '{' initial_value_expression_list '}'
 | '{' initial_value_expression_list ',' '}'

 initial_value_expression_list:
 initial_value_expression
 | initial_value_expression_list ',' initial_value_expression

 initial_value:
 integer {inz(i_int,#1);}
 | '-' integer {inz(i_int,-#2);}
 | floatcon {inz(i_float,#1);}
 | '-' floatcon {inz(i_negfloat,#2);}
 | identifier {inz(i_idn,#1);}
 | '&' identifier {inz(i_idn,#2);}
 | string {inz(i_string,#1);}

 initial_value_expression:
 constant {inz(i_int,#1);}
 | initial_value

 # declarations #

 declaration_list:
 declaration
 | declaration_list declaration

 declaration:
 decl_specifiers init_declarator_list ';'
 | literal_type_specifier ';'

 decl_specifiers:
 type_specifier {attrib(-1,#1);}
 | sc_specifier type_specifier {attrib(#1,#2);}
 | type_specifier sc_specifier {attrib(#2,#1);}

 type_specifier:
 type_identifier
 | literal_type_specifier

 literal_type_specifier:
 INT {val=TINT;}
 | CHAR {val=TCHAR;}
 | FLOAT {val=TFLOAT;}
 | DOUBLE {val=TDOUBLE;}
 | LONG {val=TINT;}
 | LONG INT {val=TINT;}
 | SHORT {val=TINT;}
 | SHORT INT {val=TINT;}
 | LONG FLOAT {val=TDOUBLE;}
 | UNSIGNED {val=TINT;}
 | UNSIGNED INT {val=TINT;}
 | struct '{' type_decl_list '}' {val=astruct(NULL,#3);}
 | struct $identifier '{' type_decl_list '}' {val=astruct(#2,#4);}
 | struct identifier {val=aostruct(#2);}

 sc_specifier:
 AUTO {val=c_auto;}
 | STATIC {val=c_static;}
 | EXTERN {val=c_extern;}
 | REGISTER {val=c_auto;}
 | TYPEDEF {val=c_typedef;}

 declarator_list:
 declarator
 | declarator_list ',' declarator 

 declarator:
 dclr {val=adeclr(maktyp());}
 | identifier ':' constant {val=adeclr(afield(#1,#3));}
 | ':' constant {val=adeclr(afield(-1,#2));}

 $declarator:
 dclr {aiinz(adeclr(maktyp()));}

 dclr:
 '*' dclr {val=adclr(#2,MPTR);}
 | dclr '(' ')' {val=adclr(#1,MFUNC);}
 | dclr '[' ']' {val=adclr(#1,MARRAY,1);}
 | dclr '[' constant ']' {val=adclr(#1,MARRAY,#3);}
 | identifier {val=adclr(0,0);}
 | '(' dclr ')' {val=#2;}

 function_declarator:
 '*' function_declarator {val=adclr(#2,MPTR);}
 | function_declarator '(' ')' {val=adclr(#1,MFUNC);}
 | function_declarator '[' ']' {val=adclr(#1,MARRAY,1);}
 | function_declarator '[' constant ']' {val=adclr(#1,MARRAY,#3);}
 | identifier '(' ')' {val=adclr(adclr(0,0),MFUNC);
 parml=0;}
 | identifier '(' parameter_list ')' {val=adclr(adclr(0,0),MFUNC);
 parml=#3;}
 | '(' function_declarator ')' {val=#2;}

 parameter_list:
 identifier {val=push(#1);}
 | parameter_list ',' identifier {push(#3);}

 formal_decl_list:
 formal_declaration
 | formal_decl_list formal_declaration

 formal_declaration:
 type_declaration
 | REGISTER type_declaration

 type_decl_list:
 type_declaration
 | type_decl_list type_declaration

 type_declaration:
 $type_specifier declarator_list ';' {in_type_def=0;
 val=#2;}

 $type_specifier:
 type_specifier {in_type_def=1;
 attrib(-1,#1);}

 # statements #

 statement_list:
 statement
 | statement_list statement {val=astmtl(#1,#2);}

 statement:
 expression ';' {val=aexprstmt(#1);}
 | compound_statement
 | IF '(' expression ')' statement {val=aif(#3,#5,0);}
 | IF '(' expression ')' statement ELSE statement {val=aif(#3,#5,#7);}
 | while '(' expression ')' statement {val=awhile(#3,#5);}
 | for '(' .expression ';' .expression ';' .expression ')' statement
 {val=afor(#3,#5,#7,#9);}
 | do statement WHILE '(' expression ')' ';' {val=ado(#2,#5);}
 | switch '(' expression ')' statement {val=aswitch(#3,#5);}
 | CASE constant ':' statement {val=acase(#2,#4);}
 | DEFAULT ':' statement {val=adefault(#3);}
 | BREAK ';' {val=abreak();}
 | CONTINUE ';' {val=acontinue();}
 | RETURN ';' {val=areturn(0);}
 | RETURN expression ';' {val=areturn(#2);}
 | GOTO lexpression ';' {val=agoto(#2);}
 | identifier ':' statement {val=alabel(#1,#3);}
 | ENTRY identifier ':' statement {val=aentry(#2,#4);}
 | ';' {val=anull();} 

 # expressions #

 .expression:
 expression
 | {val=0;}

 expression_list:
 expression = '='
 | expression_list ',' expression {val=aelist(#1,#3);}

 expression:
 expression '*' expression {val=node(n_times,#1,#3);}
 | expression '/' expression {val=node(n_div,#1,#3);}
 | expression '%' expression {val=node(n_mod,#1,#3);}
 | expression '+' expression {val=node(n_plus,#1,#3);}
 | expression '-' expression {val=node(n_minus,#1,#3);}
 | expression '<<' expression {val=node(n_ls,#1,#3);}
 | expression '>>' expression {val=node(n_rs,#1,#3);}
 | expression '<' expression {val=node(n_lt,#1,#3);}
 | expression '>' expression {val=node(n_gt,#1,#3);}
 | expression '<=' expression {val=node(n_le,#1,#3);}
 | expression '>=' expression {val=node(n_ge,#1,#3);}
 | expression '==' expression {val=node(n_eq,#1,#3);}
 | expression '!=' expression {val=node(n_ne,#1,#3);}
 | expression '&' expression {val=node(n_band,#1,#3);}
 | expression '^' expression {val=node(n_bxor,#1,#3);}
 | expression '|' expression {val=node(n_bior,#1,#3);}
 | expression '&&' expression {val=node(n_tv_and,#1,#3);}
 | expression '||' expression {val=node(n_tv_or,#1,#3);}
 | expression '?' expression ':' expression
 {val=node(n_qmark,#1,node(n_colon,#3,#5));}
 | expression '=' expression {val=node(n_assign,#1,#3);}
 | expression '=op' expression {val=node(n_ars+#2,#1,#3);}
 | expression ',' expression {val=node(n_comma,#1,#3);}
 | term 

 # the following productions are ordered very carefully so that the
 desired thing is done in the case of a R/R conflict #

 lexpression:
 expression
 | identifier {val=aidn(alidn(#1));}

 fterm:
 term
 | identifier {val=aidn(afidn(#1));}

 type_identifier:
 identifier {val=atidn(#1);}

 term:
 term '++' {val=node(n_inca,#1);}
 | term '--' {val=node(n_deca,#1);}
 | '*' term {val=node(n_star,#2);}
 | '&' term {val=node(n_addr,#2);}
 | '-' term {val=node(n_uminus,#2);}
 | '!' term {val=node(n_tvnot,#2);}
 | '~' term {val=node(n_bnot,#2);}
 | '++' term {val=node(n_incb,#2);}
 | '--' term {val=node(n_decb,#2);}
 | SIZEOF term {val=node(n_sizeof,#2);}
 | SIZEOF '(' cast_type ')' = SIZEOF
 {val=node(n_int,1);} # hack #
 | '(' cast_type ')' term = '++'
 {val=#4;} # hack #
 | term '[' expression ']' {val=asubscript(#1,#3);}
 | fterm '(' expression_list ')' {val=acall(#1,#3);}
 | fterm '(' ')' {val=acall(#1,0);}
 | term '.' identifier {val=adot(#1,#3);}
 | term '->' identifier {val=aptr(#1,#3);}
 | identifier {val=aidn(aeidn(#1));}
 | integer {val=node(n_int,#1);}
 | floatcon {val=node(n_float,#1);}
 | string {val=node(n_string,#1);}
 | '(' expression ')' {val=#2;}

 cast_type: literal_type_specifier null_decl

 null_decl: # empty #
 | '(' ')'
 | '(' null_decl ')' '(' ')'
 | '*' null_decl
 | null_decl '[' ']'
 | null_decl '[' constant ']'
 | '(' null_decl ')'

 while: WHILE {apshw();}
 do: DO {apshd();}
 for: FOR {apshf();}
 switch: SWITCH {apshs();}
 struct: STRUCT {strlev++;}
 $identifier: identifier {val=astridn(#1);}
 begin: '{' {abegin();}
 end: '}' {aend();}

 constant:
 constant '*' constant {val=#1*#3;}
 | constant '/' constant {val=#1/#3;}
 | constant '%' constant {val=#1%#3;}
 | constant '+' constant {val=#1+#3;}
 | constant '-' constant {val=#1-#3;}
 | constant '<<' constant {val=#1<<#3;}
 | constant '>>' constant {val=#1>>#3;}
 | constant '<' constant {val=#1<#3;}
 | constant '>' constant {val=#1>#3;}
 | constant '<=' constant {val=#1<=#3;}
 | constant '>=' constant {val=#1>=#3;}
 | constant '==' constant {val=#1==#3;}
 | constant '!=' constant {val=#1!=#3;}
 | constant '&' constant {val=#1}
 | constant '^' constant {val=#1^#3;}
 | constant '|' constant {val=#1|#3;}
 | constant '&&' constant {val=#1&}
 | constant '||' constant {val=#1||#3;}
 | constant '?' constant ':' constant
 {val=(#1?#3:#5);}
 | c_term 

 c_term:
 '-' c_term {val= -#2;}
 | '!' c_term {val= !#2;}
 | '~' c_term {val= ~#2;}
 | integer
 | '(' constant ')' {val=#2;}



[-- Attachment #2: Type: text/html, Size: 15539 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* [TUHS] Archaic yacc C grammar
@ 2018-10-28 21:34 Lars Brinkhoff
  2018-10-29  3:00 ` Steve Johnson
  0 siblings, 1 reply; 14+ messages in thread
From: Lars Brinkhoff @ 2018-10-28 21:34 UTC (permalink / raw)
  To: tuhs

Hello,

This is Alan Snyder's C grammar.  It's supposedly for yacc, but it's
probably using some really ancient version.  Maybe from when Alan did a
stint at Bell labs and converted yacc from B to C.

Does anyone recognize this type of yacc input?  I don't have the
corresponding yacc version, and the one in V6 isn't happy about this
file.  What would it take to update the grammar for V6 yacc?  Add in
some %term, replace \\ with %%?



	#     C GRAMMAR     #
	#    28 May 1978    #
	#    Alan Snyder    #


#	26 acceptable conflicts:

	2 S/R conflicts for (parsing) ambiguity between
		declarators and function_declarators
	1 S/R conflict for the C ELSE ambiguity
	4 R/R conflicts for the (parsing) problem with regard
		to integer constants as initial_values
	12 R/R conflicts for the (parsing) problem with regard
		to identifiers in function calls
	1 R/R conflict for the (parsing) problem with regard
		to identifiers in goto statements
	4 R/R conflicts and 1 S/R conflict for TYPEDEFs
	1 S/R conflict for ambiguous cast types
		(int ()) = (int x()) not (int (x))

	Approximate description:

 18	S/R	(	shift 37	reduce 141
 50	S/R	(	shift 37	reduce 71
 81	S/R	(	shift 37	reduce 71
113	R/R	(	reduce 141	reduce 140
113	R/R	(	reduce 159	reduce 140
113	R/R	*	reduce 159	reduce 141
113	S/R	:	shift 199	reduce 141
183	R/R	,	reduce 203	reduce 24
183	R/R	}	reduce 203	reduce 24
204	R/R	(	reduce 159	reduce 140
206	R/R	(	reduce 148	reduce 139
207	R/R	(	reduce 147	reduce 139
208	R/R	(	reduce 145	reduce 139
209	R/R	(	reduce 144	reduce 139
210	R/R	(	reduce 146	reduce 139
211	R/R	(	reduce 149	reduce 139
212	R/R	(	reduce 150	reduce 139
215	R/R	(	reduce 159	reduce 140
215	R/R	;	reduce 159	reduce 138
225	R/R	(	reduce 151	reduce 139
228	R/R	(	reduce 159	reduce 140
284	R/R	,	reduce 203	reduce 25
284	R/R	}	reduce 203	reduce 25
291	S/R	)	shift 339	reduce 165
343	R/R	(	reduce 153	reduce 139
360	S/R	ELSE	shift 369	reduce 94

#

	#     terminal symbols     #

';' '}' '{' ']' '[' ')' '(' ':'
',' '.' '?' '~' '!' '&' '|' '^'
'%' '/' '*' '-' '+' '=' '<' '>'
'++' '--' '==' '!=' '<=' '>=' '<<' '>>'
'->' '=op' '&&' '||' 'c'
INT CHAR FLOAT DOUBLE STRUCT AUTO STATIC
EXTERN RETURN GOTO IF ELSE SWITCH
BREAK CONTINUE WHILE DO FOR DEFAULT CASE
ENTRY REGISTER SIZEOF LONG SHORT UNSIGNED TYPEDEF 'l'
'm' 'n' 'o' 'p' 'q' 'r' 's'
identifier integer floatcon string

	#     precedence information     #

\< ','
\> '=' '=op'
\> '?' ':'
\< '||'
\< '&&'
\< '|'
\< '^'
\< '&'
\< '==' '!='
\< '<' '>' '<=' '>='
\< '<<' '>>'
\< '+' '-'
\< '*' '/' '%'
\> '!' '~'
\> '++' '--' SIZEOF
\< '[' '(' '.' '->'

\\

	#     external definitions     #

program:
	  program external_definition
	|

external_definition:
	  declaration
	| function_definition

function_definition:
	  function_specification function_body		{afdef(#1,#2);}

function_specification:
	  decl_specifiers function_declarator		{val=afdcl(1);}
	| function_declarator				{val=afdcl(0);}

function_body:
	  formal_declarations compound_statement	{val=#2;}

formal_declarations:
	  formal_decl_list				{afpdcl();}
	| 						{afpdcl();}

compound_statement:
	  begin declaration_list statement_list end	{val=#3;}
	| begin statement_list end			{val=#2;}

init_declarator_list:
	  init_declarator
	| init_declarator_list ',' init_declarator 

init_declarator:
	  $declarator initializer		{aidecl();}
	| declarator				{aidecl();}
	| function_declarator			{adeclr(maktyp());}

initializer:
	  initial_value
	| '{' initial_value_expression_list '}'
	| '{' initial_value_expression_list ',' '}'

initial_value_expression_list:
	  initial_value_expression
	| initial_value_expression_list ',' initial_value_expression

initial_value:
	  integer				{inz(i_int,#1);}
	| '-' integer				{inz(i_int,-#2);}
	| floatcon				{inz(i_float,#1);}
	| '-' floatcon				{inz(i_negfloat,#2);}
	| identifier				{inz(i_idn,#1);}
	| '&' identifier			{inz(i_idn,#2);}
	| string 				{inz(i_string,#1);}

initial_value_expression:
	  constant				{inz(i_int,#1);}
	| initial_value

	#     declarations     #

declaration_list:
	  declaration
	| declaration_list declaration

declaration:
	  decl_specifiers init_declarator_list ';'
	| literal_type_specifier ';'

decl_specifiers:
	  type_specifier			{attrib(-1,#1);}
	| sc_specifier type_specifier		{attrib(#1,#2);}
	| type_specifier sc_specifier		{attrib(#2,#1);}

type_specifier:
	  type_identifier
	| literal_type_specifier

literal_type_specifier:
	  INT					{val=TINT;}
	| CHAR					{val=TCHAR;}
	| FLOAT					{val=TFLOAT;}
	| DOUBLE				{val=TDOUBLE;}
	| LONG					{val=TINT;}
	| LONG INT				{val=TINT;}
	| SHORT					{val=TINT;}
	| SHORT INT				{val=TINT;}
	| LONG FLOAT				{val=TDOUBLE;}
	| UNSIGNED				{val=TINT;}
	| UNSIGNED INT				{val=TINT;}
	| struct '{' type_decl_list '}'			{val=astruct(NULL,#3);}
	| struct $identifier '{' type_decl_list '}'	{val=astruct(#2,#4);}
	| struct identifier	 			{val=aostruct(#2);}

sc_specifier:
	  AUTO					{val=c_auto;}
	| STATIC				{val=c_static;}
	| EXTERN				{val=c_extern;}
	| REGISTER				{val=c_auto;}
	| TYPEDEF				{val=c_typedef;}

declarator_list:
	  declarator
	| declarator_list ',' declarator 

declarator:
	  dclr					{val=adeclr(maktyp());}
	| identifier ':' constant		{val=adeclr(afield(#1,#3));}
	| ':' constant				{val=adeclr(afield(-1,#2));}

$declarator:
	  dclr					{aiinz(adeclr(maktyp()));}

dclr:
	'*' dclr				{val=adclr(#2,MPTR);}
	| dclr '(' ')'				{val=adclr(#1,MFUNC);}
	| dclr '[' ']'				{val=adclr(#1,MARRAY,1);}
	| dclr '[' constant ']'			{val=adclr(#1,MARRAY,#3);}
	| identifier  				{val=adclr(0,0);}
	| '(' dclr ')' 				{val=#2;}

function_declarator:
	  '*' function_declarator		{val=adclr(#2,MPTR);}
	| function_declarator '(' ')'		{val=adclr(#1,MFUNC);}
	| function_declarator '[' ']'		{val=adclr(#1,MARRAY,1);}
	| function_declarator '[' constant ']'	{val=adclr(#1,MARRAY,#3);}
	| identifier '(' ')'			{val=adclr(adclr(0,0),MFUNC);
							parml=0;}
	| identifier '(' parameter_list ')'	{val=adclr(adclr(0,0),MFUNC);
							parml=#3;}
	| '(' function_declarator ')'		{val=#2;}

parameter_list:
	  identifier				{val=push(#1);}
	| parameter_list ',' identifier		{push(#3);}

formal_decl_list:
	  formal_declaration
	| formal_decl_list formal_declaration

formal_declaration:
	  type_declaration
	| REGISTER type_declaration

type_decl_list:
	  type_declaration
	| type_decl_list type_declaration

type_declaration:
	  $type_specifier declarator_list ';'	{in_type_def=0;
						val=#2;}

$type_specifier:
	  type_specifier			{in_type_def=1;
						attrib(-1,#1);}

	#     statements     #

statement_list:
	  statement
	| statement_list statement		{val=astmtl(#1,#2);}

statement:
	  expression  ';'					{val=aexprstmt(#1);}
	| compound_statement
	| IF '(' expression ')' statement	 		{val=aif(#3,#5,0);}
	| IF '(' expression ')' statement ELSE statement	{val=aif(#3,#5,#7);}
	| while '(' expression ')' statement	 		{val=awhile(#3,#5);}
	| for '(' .expression ';' .expression ';' .expression ')' statement
								{val=afor(#3,#5,#7,#9);}
	| do statement WHILE '(' expression ')' ';'		{val=ado(#2,#5);}
	| switch '(' expression ')' statement			{val=aswitch(#3,#5);}
	| CASE constant ':' statement				{val=acase(#2,#4);}
	| DEFAULT ':' statement					{val=adefault(#3);}
	| BREAK ';'						{val=abreak();}
	| CONTINUE ';'						{val=acontinue();}
	| RETURN ';'						{val=areturn(0);}
	| RETURN expression ';'					{val=areturn(#2);}
	| GOTO lexpression ';'					{val=agoto(#2);}
	| identifier ':' statement				{val=alabel(#1,#3);}
	| ENTRY identifier ':' statement			{val=aentry(#2,#4);}
	| ';' 							{val=anull();} 


	#     expressions     #

.expression:
	  expression
	|			{val=0;}

expression_list:
	  expression	\= '='
	| expression_list ',' expression 		{val=aelist(#1,#3);}

expression:
	  expression '*' expression		{val=node(n_times,#1,#3);}
	| expression '/' expression		{val=node(n_div,#1,#3);}
	| expression '%' expression		{val=node(n_mod,#1,#3);}
	| expression '+' expression		{val=node(n_plus,#1,#3);}
	| expression '-' expression		{val=node(n_minus,#1,#3);}
	| expression '<<' expression		{val=node(n_ls,#1,#3);}
	| expression '>>' expression		{val=node(n_rs,#1,#3);}
	| expression '<' expression		{val=node(n_lt,#1,#3);}
	| expression '>' expression		{val=node(n_gt,#1,#3);}
	| expression '<=' expression		{val=node(n_le,#1,#3);}
	| expression '>='  expression		{val=node(n_ge,#1,#3);}
	| expression '=='  expression		{val=node(n_eq,#1,#3);}
	| expression '!='  expression		{val=node(n_ne,#1,#3);}
	| expression '&' expression		{val=node(n_band,#1,#3);}
	| expression '^' expression		{val=node(n_bxor,#1,#3);}
	| expression '|' expression		{val=node(n_bior,#1,#3);}
	| expression '&&' expression		{val=node(n_tv_and,#1,#3);}
	| expression '||' expression		{val=node(n_tv_or,#1,#3);}
	| expression '?' expression ':' expression
				{val=node(n_qmark,#1,node(n_colon,#3,#5));}
	| expression '=' expression		{val=node(n_assign,#1,#3);}
	| expression '=op' expression		{val=node(n_ars+#2,#1,#3);}
	| expression ',' expression		{val=node(n_comma,#1,#3);}
	| term 

# the following productions are ordered very carefully so that the
  desired thing is done in the case of a R/R conflict #

lexpression:
	  expression
	| identifier			{val=aidn(alidn(#1));}

fterm:
	  term
	| identifier			{val=aidn(afidn(#1));}

type_identifier:
	  identifier			{val=atidn(#1);}

term:
	  term '++'			{val=node(n_inca,#1);}
	| term '--'			{val=node(n_deca,#1);}
	| '*' term			{val=node(n_star,#2);}
	| '&' term			{val=node(n_addr,#2);}
	| '-' term			{val=node(n_uminus,#2);}
	| '!' term			{val=node(n_tvnot,#2);}
	| '~' term			{val=node(n_bnot,#2);}
	| '++' term			{val=node(n_incb,#2);}
	| '--' term			{val=node(n_decb,#2);}
	| SIZEOF term			{val=node(n_sizeof,#2);}
	| SIZEOF '(' cast_type ')' \= SIZEOF
					{val=node(n_int,1);} # hack #
	| '(' cast_type ')' term \= '++'
					{val=#4;} # hack #
	| term '[' expression ']'	{val=asubscript(#1,#3);}
	| fterm '(' expression_list ')'	{val=acall(#1,#3);}
	| fterm '(' ')'			{val=acall(#1,0);}
	| term '.' identifier		{val=adot(#1,#3);}
	| term '->' identifier		{val=aptr(#1,#3);}
	| identifier			{val=aidn(aeidn(#1));}
	| integer			{val=node(n_int,#1);}
	| floatcon			{val=node(n_float,#1);}
	| string			{val=node(n_string,#1);}
	| '(' expression ')' 		{val=#2;}

cast_type:	   literal_type_specifier null_decl

null_decl:	   # empty #
		|  '(' ')'
		|  '(' null_decl ')' '(' ')'
		|  '*' null_decl
		|  null_decl '[' ']'
		|  null_decl '[' constant ']'
		|  '(' null_decl ')'

while:		  WHILE			{apshw();}
do:		  DO			{apshd();}
for:		  FOR			{apshf();}
switch:		  SWITCH		{apshs();}
struct:		  STRUCT		{strlev++;}
$identifier:	  identifier		{val=astridn(#1);}
begin:		  '{'			{abegin();}
end:		  '}'			{aend();}

constant:
	  constant '*' constant		{val=#1*#3;}
	| constant '/' constant		{val=#1/#3;}
	| constant '%' constant		{val=#1%#3;}
	| constant '+' constant		{val=#1+#3;}
	| constant '-' constant		{val=#1-#3;}
	| constant '<<' constant	{val=#1<<#3;}
	| constant '>>' constant	{val=#1>>#3;}
	| constant '<' constant		{val=#1<#3;}
	| constant '>' constant		{val=#1>#3;}
	| constant '<=' constant	{val=#1<=#3;}
	| constant '>='  constant	{val=#1>=#3;}
	| constant '=='  constant	{val=#1==#3;}
	| constant '!='  constant	{val=#1!=#3;}
	| constant '&' constant		{val=#1&#3;}
	| constant '^' constant		{val=#1^#3;}
	| constant '|' constant		{val=#1|#3;}
	| constant '&&' constant	{val=#1&&#3;}
	| constant '||' constant	{val=#1||#3;}
	| constant '?' constant ':' constant
					{val=(#1?#3:#5);}
	| c_term 

c_term:
	  '-' c_term		{val= -#2;}
	| '!' c_term		{val= !#2;}
	| '~' c_term		{val= ~#2;}
	| integer
	| '(' constant ')'	{val=#2;}


^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2018-11-03 23:08 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-31 15:39 [TUHS] Archaic yacc C grammar Noel Chiappa
  -- strict thread matches above, loose matches on Subject: below --
2018-10-28 21:34 Lars Brinkhoff
2018-10-29  3:00 ` Steve Johnson
2018-10-29  7:31   ` Lars Brinkhoff
2018-10-29 17:52     ` Steve Johnson
2018-10-29 18:37       ` Warner Losh
2018-10-30  8:16         ` Lars Brinkhoff
2018-11-03 21:50           ` Steve Johnson
2018-10-29 19:02       ` David
2018-10-30 22:01         ` Steve Johnson
2018-10-31  0:58           ` Larry McVoy
2018-10-31 13:49             ` Clem Cole
2018-11-03 22:14             ` Steve Johnson
2018-10-31  6:09           ` Lars Brinkhoff

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).