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

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

typedef in old C

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

Contents

  typedef in old C Bart <bc@freeuk.com> - 2022-12-13 13:45 +0000
    Re: typedef in old C Thiago Adams <thiago.adams@gmail.com> - 2022-12-13 06:42 -0800
      Re: typedef in old C Thiago Adams <thiago.adams@gmail.com> - 2022-12-13 06:46 -0800
        Re: typedef in old C Bart <bc@freeuk.com> - 2022-12-13 15:56 +0000
          Re: typedef in old C Kaz Kylheku <864-117-4973@kylheku.com> - 2022-12-13 18:07 +0000
            Re: typedef in old C Thiago Adams <thiago.adams@gmail.com> - 2022-12-13 11:11 -0800
    Re: typedef in old C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-13 16:40 +0000
      Re: typedef in old C scott@slp53.sl.home (Scott Lurndal) - 2022-12-13 17:05 +0000
      Re: typedef in old C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-13 10:27 -0800
      Re: typedef in old C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-18 17:25 -0800
    Re: typedef in old C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-13 10:30 -0800
    Re: typedef in old C luser droog <luser.droog@gmail.com> - 2022-12-14 09:42 -0800
      Re: typedef in old C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-14 20:59 +0000
        Re: typedef in old C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-14 13:44 -0800
          Re: typedef in old C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-15 02:46 +0000
        Re: typedef in old C scott@slp53.sl.home (Scott Lurndal) - 2022-12-15 15:01 +0000
          Re: typedef in old C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-15 17:07 +0000
        Re: typedef in old C luser droog <luser.droog@gmail.com> - 2022-12-15 18:34 -0800
          Re: typedef in old C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-16 17:41 +0000
    Re: typedef in old C Bonita Montero <Bonita.Montero@gmail.com> - 2022-12-17 07:54 +0100

#168526 — typedef in old C

I was looking at the 1983 C sources of PostScript (via 
https://computerhistory.org/blog/postscript-a-digital-printing-press/).

It uses typedef like this:

   typedef long int integer;
   typedef unsigned integer Offset;

That is, being able to apply 'unsigned' to a typedef-ed name, rather 
than any of 'char short int long'.

I guess this is not legal C now; I just wondered at what point it 
stopped being legal, if it ever was (perhaps compilers were just more lax).

[toc] | [next] | [standalone]

#168528

On Tuesday, December 13, 2022 at 10:45:34 AM UTC-3, Bart wrote:
> I was looking at the 1983 C sources of PostScript (via 
> https://computerhistory.org/blog/postscript-a-digital-printing-press/). 
> 
> It uses typedef like this: 
> 
> typedef long int integer; 
> typedef unsigned integer Offset; 
> 
> That is, being able to apply 'unsigned' to a typedef-ed name, rather 
> than any of 'char short int long'. 
> 
> I guess this is not legal C now; I just wondered at what point it 
> stopped being legal, if it ever was (perhaps compilers were just more lax).

Interesting.

I have posted here a question in the past how to "merge" typedef definitions..
The separation of type specifier and declarator in C makes everything more complex.

things like:

typedef int A[2];
typedef A *B [1];

 B is 
 int (* [1]) [2]

I think this is one of the biggest problem of C.. but this bothers more implementers.

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

#168529

On Tuesday, December 13, 2022 at 11:42:43 AM UTC-3, Thiago Adams wrote:
...
> I think this is one of the biggest problem of C.. but this bothers more implementers.

The data representation of C types are incredible complex. 

Also types can have extra parentheses that are useless like:
int (((a)));

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

#168532

On 13/12/2022 14:46, Thiago Adams wrote:
> On Tuesday, December 13, 2022 at 11:42:43 AM UTC-3, Thiago Adams wrote:
> ...
>> I think this is one of the biggest problem of C.. but this bothers more implementers.
> 
> The data representation of C types are incredible complex.
> 
> Also types can have extra parentheses that are useless like:
> int (((a)));

Most languages will allow (((a))) in expressions too; it is not unusual.

What's different with C is treating a type specification as though it 
was an expression too, which can be confusing if you come across it 
unexpectedly. So:

     f(x);

looks like a function call, but could equally be declaring 'x' of type 
'f', depending on what 'f' actually is.

Mixing up expression syntax and type syntax was deliberate, but also a 
mistake.

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

#168537

On 2022-12-13, Bart <bc@freeuk.com> wrote:
> On 13/12/2022 14:46, Thiago Adams wrote:
>> On Tuesday, December 13, 2022 at 11:42:43 AM UTC-3, Thiago Adams wrote:
>> ...
>>> I think this is one of the biggest problem of C.. but this bothers more implementers.
>> 
>> The data representation of C types are incredible complex.
>> 
>> Also types can have extra parentheses that are useless like:
>> int (((a)));
>
> Most languages will allow (((a))) in expressions too; it is not unusual.
>
> What's different with C is treating a type specification as though it 
> was an expression too, which can be confusing if you come across it 
> unexpectedly. So:
>
>      f(x);
>
> looks like a function call, but could equally be declaring 'x' of type 
> 'f', depending on what 'f' actually is.

Similarly:

  (f)(x)

can be casting (x) to type f, or calling f(x).

> Mixing up expression syntax and type syntax was deliberate, but also a 
> mistake.

They aren't deep abiguities in the sense that while scanning the f
token, we can resolve it by looking up f, and giving it a token category
like "type-name" versus "identifier". Then the parser just has rules
that involve "type-name".

Still, anyone who just wants an accurate C parser has to implement
declarations, which is annoying.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

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

#168540

On Tuesday, December 13, 2022 at 3:07:46 PM UTC-3, Kaz Kylheku wrote:
> On 2022-12-13, Bart <b...@freeuk.com> wrote: 
> > On 13/12/2022 14:46, Thiago Adams wrote: 
> >> On Tuesday, December 13, 2022 at 11:42:43 AM UTC-3, Thiago Adams wrote: 
> >> ... 
> >>> I think this is one of the biggest problem of C.. but this bothers more implementers. 
> >> 
> >> The data representation of C types are incredible complex. 
> >> 
> >> Also types can have extra parentheses that are useless like: 
> >> int (((a))); 
> > 
> > Most languages will allow (((a))) in expressions too; it is not unusual. 
> > 
> > What's different with C is treating a type specification as though it 
> > was an expression too, which can be confusing if you come across it 
> > unexpectedly. So: 
> > 
> > f(x); 
> > 
> > looks like a function call, but could equally be declaring 'x' of type 
> > 'f', depending on what 'f' actually is.
> Similarly: 
> 
> (f)(x) 
> 
> can be casting (x) to type f, or calling f(x).
> > Mixing up expression syntax and type syntax was deliberate, but also a 
> > mistake.
> They aren't deep abiguities in the sense that while scanning the f 
> token, we can resolve it by looking up f, and giving it a token category 
> like "type-name" versus "identifier". Then the parser just has rules 
> that involve "type-name". 
> 
> Still, anyone who just wants an accurate C parser has to implement 
> declarations, which is annoying. 

The problem is not only parsing..it is type manipulation.
imagine to calculate the size of sizeof(f)

void (*f[10])(int a[2], void (*pf)(int));

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

#168535

Bart <bc@freeuk.com> writes:

> I was looking at the 1983 C sources of PostScript (via
> https://computerhistory.org/blog/postscript-a-digital-printing-press/).
>
> It uses typedef like this:
>
>   typedef long int integer;
>   typedef unsigned integer Offset;
>
> That is, being able to apply 'unsigned' to a typedef-ed name, rather
> than any of 'char short int long'.
>
> I guess this is not legal C now; I just wondered at what point it
> stopped being legal, if it ever was (perhaps compilers were just more
> lax).

I doubt it has ever been legal.  Even K&R1 has the wording that rules it
out.  Pre-K&R1 C might have been more lax, but for most of the time
before K&R1 C did not even have unsigned!

I wonder what else this generous compiler permitted.  Could one do

  typedef double number;
  typedef long number hi_prec_num;

for example?  I doubt it.

-- 
Ben.

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

#168536

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>Bart <bc@freeuk.com> writes:
>
>> I was looking at the 1983 C sources of PostScript (via
>> https://computerhistory.org/blog/postscript-a-digital-printing-press/).
>>
>> It uses typedef like this:
>>
>>   typedef long int integer;
>>   typedef unsigned integer Offset;
>>
>> That is, being able to apply 'unsigned' to a typedef-ed name, rather
>> than any of 'char short int long'.
>>
>> I guess this is not legal C now; I just wondered at what point it
>> stopped being legal, if it ever was (perhaps compilers were just more
>> lax).
>
>I doubt it has ever been legal.  Even K&R1 has the wording that rules it
>out.  Pre-K&R1 C might have been more lax, but for most of the time
>before K&R1 C did not even have unsigned!

It probably worked because:

#define unsigned

preceeded it in the translation unit.

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

#168538

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Bart <bc@freeuk.com> writes:
>
>> I was looking at the 1983 C sources of PostScript (via
>> https://computerhistory.org/blog/postscript-a-digital-printing-press/).
>>
>> It uses typedef like this:
>>
>>   typedef long int integer;
>>   typedef unsigned integer Offset;
>>
>> That is, being able to apply 'unsigned' to a typedef-ed name, rather
>> than any of 'char short int long'.
>>
>> I guess this is not legal C now; I just wondered at what point it
>> stopped being legal, if it ever was (perhaps compilers were just more
>> lax).
>
> I doubt it has ever been legal.  Even K&R1 has the wording that rules it
> out.  Pre-K&R1 C might have been more lax, but for most of the time
> before K&R1 C did not even have unsigned!

Or typedef.

The 1975 C reference manual has neither typedef nor unsigned (nor long,
nor short).  K&R1 (1978) has both.  I don't know which was added first.

> I wonder what else this generous compiler permitted.  Could one do
>
>   typedef double number;
>   typedef long number hi_prec_num;
>
> for example?  I doubt it.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

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

#168590

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Bart <bc@freeuk.com> writes:
>
>> I was looking at the 1983 C sources of PostScript (via
>> https://computerhistory.org/blog/postscript-a-digital-printing-press/).
>>
>> It uses typedef like this:
>>
>>   typedef long int integer;
>>   typedef unsigned integer Offset;
>>
>> That is, being able to apply 'unsigned' to a typedef-ed name, rather
>> than any of 'char short int long'.
>>
>> I guess this is not legal C now;  I just wondered at what point it
>> stopped being legal, if it ever was (perhaps compilers were just more
>> lax).
>
> I doubt it has ever been legal.  Even K&R1 has the wording that rules it
> out.  Pre-K&R1 C might have been more lax, but for most of the time
> before K&R1 C did not even have unsigned!
>
> I wonder what else this generous compiler permitted.  Could one do
>
>   typedef double number;
>   typedef long number hi_prec_num;
>
> for example?  I doubt it.

Most likely the issue is not the compiler but the code.  This
body of code has all sorts of problems, including syntax errors
and some things that are obviously wrong or incomplete.  If you
try compiling it I think you'll see what I mean.

Incidentally, there are pretty clear signs of a Mesa influence,
which isn't surprising since the principals came from Xerox PARC.

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

#168539

Bart <bc@freeuk.com> writes:
> I was looking at the 1983 C sources of PostScript (via
> https://computerhistory.org/blog/postscript-a-digital-printing-press/).
>
> It uses typedef like this:
>
>   typedef long int integer;
>   typedef unsigned integer Offset;
>
> That is, being able to apply 'unsigned' to a typedef-ed name, rather
> than any of 'char short int long'.
>
> I guess this is not legal C now; I just wondered at what point it
> stopped being legal, if it ever was (perhaps compilers were just more
> lax).

Apparently it was never documented as legal.  A compiler that accepted
it presumably had a bug (or perhaps an extension).  (1983 was 5 years
after K&R1, which apparently made it clear that it's invalid.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

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

#168545

On Tuesday, December 13, 2022 at 7:45:34 AM UTC-6, Bart wrote:
> I was looking at the 1983 C sources of PostScript (via 
> https://computerhistory.org/blog/postscript-a-digital-printing-press/). 
> 
> It uses typedef like this: 
> 
> typedef long int integer; 
> typedef unsigned integer Offset; 
> 
> That is, being able to apply 'unsigned' to a typedef-ed name, rather 
> than any of 'char short int long'. 
> 
> I guess this is not legal C now; I just wondered at what point it 
> stopped being legal, if it ever was (perhaps compilers were just more lax).

Overall it seems to be "cutting edge" C for the time AFAICT. 
New types are used all over to convey semantic information
about the variable that also makes the selection of the concrete 
type very DRY.

Very surprising to me is the use of linked lists for the basic stacks.
Since the original application in the Apple Laserwriter was very
memory constrained, it's surprising that they spent the size of an
extra pointer on every stack element. Even unused elements have
this pointer, being linked together on their own per stack free list.

OTOH this would make it easy to initialize the stacks to use whatever
odd space was available after making big contiguous memory areas
for other stuff. You just carve up little (next pointer, object} nodes from
the desired memory and link them together into the free list. 

So maybe the memory contraints encouraged this choice even though
it appears surprising that the famous "stack based language" does not
in fact use "stacks" per se.

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

#168550

luser droog <luser.droog@gmail.com> writes:

> On Tuesday, December 13, 2022 at 7:45:34 AM UTC-6, Bart wrote:
>> I was looking at the 1983 C sources of PostScript (via 
>> https://computerhistory.org/blog/postscript-a-digital-printing-press/). 
>> 
>> It uses typedef like this: 
>> 
>> typedef long int integer; 
>> typedef unsigned integer Offset; 
>> 
>> That is, being able to apply 'unsigned' to a typedef-ed name, rather 
>> than any of 'char short int long'. 
>> 
>> I guess this is not legal C now; I just wondered at what point it 
>> stopped being legal, if it ever was (perhaps compilers were just more lax).
>
> Overall it seems to be "cutting edge" C for the time AFAICT. 
> New types are used all over to convey semantic information
> about the variable that also makes the selection of the concrete 
> type very DRY.
>
> Very surprising to me is the use of linked lists for the basic stacks.
> Since the original application in the Apple Laserwriter was very
> memory constrained, it's surprising that they spent the size of an
> extra pointer on every stack element. Even unused elements have
> this pointer, being linked together on their own per stack free list.
>
> OTOH this would make it easy to initialize the stacks to use whatever
> odd space was available after making big contiguous memory areas
> for other stuff. You just carve up little (next pointer, object} nodes from
> the desired memory and link them together into the free list.

That's the key.  It's simple.

About that time I visited a research lab developing cutting edge
distributed systems.  Around the lab the team had pinned a huge banner
bearing the words "MEMORY IS CHEAP".  When I asked about this (because
memory was /not/ cheap or plentiful in most systems at the time) I was
told that, because it /will/ be cheap and plentiful, cutting edge
software should not waste time solving a problem that will vanish by
release 2.0 (or in some cases even by the first release).

> So maybe the memory contraints encouraged this choice even though
> it appears surprising that the famous "stack based language" does not
> in fact use "stacks" per se.

What then, to your mind, is a stack?

-- 
Ben.

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

#168551

On 12/14/2022 12:59 PM, Ben Bacarisse wrote:
> luser droog <luser.droog@gmail.com> writes:
> 
>> On Tuesday, December 13, 2022 at 7:45:34 AM UTC-6, Bart wrote:
>>> I was looking at the 1983 C sources of PostScript (via
>>> https://computerhistory.org/blog/postscript-a-digital-printing-press/).
>>>
>>> It uses typedef like this:
>>>
>>> typedef long int integer;
>>> typedef unsigned integer Offset;
>>>
>>> That is, being able to apply 'unsigned' to a typedef-ed name, rather
>>> than any of 'char short int long'.
>>>
>>> I guess this is not legal C now; I just wondered at what point it
>>> stopped being legal, if it ever was (perhaps compilers were just more lax).
>>
>> Overall it seems to be "cutting edge" C for the time AFAICT.
>> New types are used all over to convey semantic information
>> about the variable that also makes the selection of the concrete
>> type very DRY.
>>
>> Very surprising to me is the use of linked lists for the basic stacks.
>> Since the original application in the Apple Laserwriter was very
>> memory constrained, it's surprising that they spent the size of an
>> extra pointer on every stack element. Even unused elements have
>> this pointer, being linked together on their own per stack free list.
>>
>> OTOH this would make it easy to initialize the stacks to use whatever
>> odd space was available after making big contiguous memory areas
>> for other stuff. You just carve up little (next pointer, object} nodes from
>> the desired memory and link them together into the free list.
> 
> That's the key.  It's simple.
> 
> About that time I visited a research lab developing cutting edge
> distributed systems.  Around the lab the team had pinned a huge banner
> bearing the words "MEMORY IS CHEAP".  When I asked about this (because
> memory was /not/ cheap or plentiful in most systems at the time) I was
> told that, because it /will/ be cheap and plentiful, cutting edge
> software should not waste time solving a problem that will vanish by
> release 2.0 (or in some cases even by the first release).
> 
>> So maybe the memory contraints encouraged this choice even though
>> it appears surprising that the famous "stack based language" does not
>> in fact use "stacks" per se.
> 
> What then, to your mind, is a stack?
> 

LIFO. Yes it can be created in thread "local" memory. I did one where 
thread local memory was used to simulate a shared memory system. Back on 
Quadros, iirc. A region allocator on the threads "stack" can be very 
useful...

https://groups.google.com/g/comp.lang.c/c/7oaJFWKVCTw/m/sSWYU9BUS_QJ

https://pastebin.com/raw/f37a23918

Some old experimental code of mine. 2009, how time goes by. wow.

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

#168554

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

> On 12/14/2022 12:59 PM, Ben Bacarisse wrote:
>> luser droog <luser.droog@gmail.com> writes:
>> 
>>> On Tuesday, December 13, 2022 at 7:45:34 AM UTC-6, Bart wrote:
>>>> I was looking at the 1983 C sources of PostScript (via
>>>> https://computerhistory.org/blog/postscript-a-digital-printing-press/).
>>>>
>>>> It uses typedef like this:
>>>>
>>>> typedef long int integer;
>>>> typedef unsigned integer Offset;
>>>>
>>>> That is, being able to apply 'unsigned' to a typedef-ed name, rather
>>>> than any of 'char short int long'.
>>>>
>>>> I guess this is not legal C now; I just wondered at what point it
>>>> stopped being legal, if it ever was (perhaps compilers were just more lax).
>>>
>>> Overall it seems to be "cutting edge" C for the time AFAICT.
>>> New types are used all over to convey semantic information
>>> about the variable that also makes the selection of the concrete
>>> type very DRY.
>>>
>>> Very surprising to me is the use of linked lists for the basic stacks.
>>> Since the original application in the Apple Laserwriter was very
>>> memory constrained, it's surprising that they spent the size of an
>>> extra pointer on every stack element. Even unused elements have
>>> this pointer, being linked together on their own per stack free list.
>>>
>>> OTOH this would make it easy to initialize the stacks to use whatever
>>> odd space was available after making big contiguous memory areas
>>> for other stuff. You just carve up little (next pointer, object} nodes from
>>> the desired memory and link them together into the free list.
>>
>> That's the key.  It's simple.
>> About that time I visited a research lab developing cutting edge
>> distributed systems.  Around the lab the team had pinned a huge banner
>> bearing the words "MEMORY IS CHEAP".  When I asked about this (because
>> memory was /not/ cheap or plentiful in most systems at the time) I was
>> told that, because it /will/ be cheap and plentiful, cutting edge
>> software should not waste time solving a problem that will vanish by
>> release 2.0 (or in some cases even by the first release).
>> 
>>> So maybe the memory contraints encouraged this choice even though
>>> it appears surprising that the famous "stack based language" does not
>>> in fact use "stacks" per se.
>>
>> What then, to your mind, is a stack?
>
> LIFO.

Sure, but since you didn't dispute that the linked list used by this C
code is a stack "per se", there was really no need to confirm your
position.

-- 
Ben.

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

#168557

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>luser droog <luser.droog@gmail.com> writes:
>
>> On Tuesday, December 13, 2022 at 7:45:34 AM UTC-6, Bart wrote:
>>> I was looking at the 1983 C sources of PostScript (via 
>>> https://computerhistory.org/blog/postscript-a-digital-printing-press/). 
>>> 
>>> It uses typedef like this: 
>>> 
>>> typedef long int integer; 
>>> typedef unsigned integer Offset; 
>>> 
>>> That is, being able to apply 'unsigned' to a typedef-ed name, rather 
>>> than any of 'char short int long'. 
>>> 
>>> I guess this is not legal C now; I just wondered at what point it 
>>> stopped being legal, if it ever was (perhaps compilers were just more lax).
>>
>> Overall it seems to be "cutting edge" C for the time AFAICT. 
>> New types are used all over to convey semantic information
>> about the variable that also makes the selection of the concrete 
>> type very DRY.
>>
>> Very surprising to me is the use of linked lists for the basic stacks.
>> Since the original application in the Apple Laserwriter was very
>> memory constrained, it's surprising that they spent the size of an
>> extra pointer on every stack element. Even unused elements have
>> this pointer, being linked together on their own per stack free list.
>>
>> OTOH this would make it easy to initialize the stacks to use whatever
>> odd space was available after making big contiguous memory areas
>> for other stuff. You just carve up little (next pointer, object} nodes from
>> the desired memory and link them together into the free list.
>
>That's the key.  It's simple.
>
>About that time I visited a research lab developing cutting edge
>distributed systems.  Around the lab the team had pinned a huge banner
>bearing the words "MEMORY IS CHEAP".  When I asked about this (because
>memory was /not/ cheap or plentiful in most systems at the time) I was
>told that, because it /will/ be cheap and plentiful, cutting edge
>software should not waste time solving a problem that will vanish by
>release 2.0 (or in some cases even by the first release).

Was that lab in San Jose?   We used a similar motto extensively when
developing our cutting edge distributed system (1989-1997).

  "Memory is not a problem".

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

#168558

scott@slp53.sl.home (Scott Lurndal) writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>luser droog <luser.droog@gmail.com> writes:
>>
>>> On Tuesday, December 13, 2022 at 7:45:34 AM UTC-6, Bart wrote:
>>>> I was looking at the 1983 C sources of PostScript (via 
>>>> https://computerhistory.org/blog/postscript-a-digital-printing-press/). 
>>>> 
>>>> It uses typedef like this: 
>>>> 
>>>> typedef long int integer; 
>>>> typedef unsigned integer Offset; 
>>>> 
>>>> That is, being able to apply 'unsigned' to a typedef-ed name, rather 
>>>> than any of 'char short int long'. 
>>>> 
>>>> I guess this is not legal C now; I just wondered at what point it 
>>>> stopped being legal, if it ever was (perhaps compilers were just more lax).
>>>
>>> Overall it seems to be "cutting edge" C for the time AFAICT. 
>>> New types are used all over to convey semantic information
>>> about the variable that also makes the selection of the concrete 
>>> type very DRY.
>>>
>>> Very surprising to me is the use of linked lists for the basic stacks.
>>> Since the original application in the Apple Laserwriter was very
>>> memory constrained, it's surprising that they spent the size of an
>>> extra pointer on every stack element. Even unused elements have
>>> this pointer, being linked together on their own per stack free list.
>>>
>>> OTOH this would make it easy to initialize the stacks to use whatever
>>> odd space was available after making big contiguous memory areas
>>> for other stuff. You just carve up little (next pointer, object} nodes from
>>> the desired memory and link them together into the free list.
>>
>>That's the key.  It's simple.
>>
>>About that time I visited a research lab developing cutting edge
>>distributed systems.  Around the lab the team had pinned a huge banner
>>bearing the words "MEMORY IS CHEAP".  When I asked about this (because
>>memory was /not/ cheap or plentiful in most systems at the time) I was
>>told that, because it /will/ be cheap and plentiful, cutting edge
>>software should not waste time solving a problem that will vanish by
>>release 2.0 (or in some cases even by the first release).
>
> Was that lab in San Jose?   We used a similar motto extensively when
> developing our cutting edge distributed system (1989-1997).
>
>   "Memory is not a problem".

No, Pittsburgh :-(

-- 
Ben.

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

#168559

On Wednesday, December 14, 2022 at 2:59:42 PM UTC-6, Ben Bacarisse wrote:
> luser droog <luser...@gmail.com> writes: 
> 
> > Very surprising to me is the use of linked lists for the basic stacks. 
> > Since the original application in the Apple Laserwriter was very 
> > memory constrained, it's surprising that they spent the size of an 
> > extra pointer on every stack element. Even unused elements have 
> > this pointer, being linked together on their own per stack free list. 
> > 
> > OTOH this would make it easy to initialize the stacks to use whatever 
> > odd space was available after making big contiguous memory areas 
> > for other stuff. You just carve up little (next pointer, object} nodes from 
> > the desired memory and link them together into the free list.
> That's the key. It's simple. 
> 
> About that time I visited a research lab developing cutting edge 
> distributed systems. Around the lab the team had pinned a huge banner 
> bearing the words "MEMORY IS CHEAP". When I asked about this (because 
> memory was /not/ cheap or plentiful in most systems at the time) I was 
> told that, because it /will/ be cheap and plentiful, cutting edge 
> software should not waste time solving a problem that will vanish by 
> release 2.0 (or in some cases even by the first release).
> > So maybe the memory contraints encouraged this choice even though 
> > it appears surprising that the famous "stack based language" does not 
> > in fact use "stacks" per se.
> What then, to your mind, is a stack? 
> 

I'd have expected to see a single TOS pointer ranging over a contiguous
set of addresses. An array representation. I also expected this because
the existing PostScript operators that copy stacks, viz. `execstack`
and `dictstack` both return their data in a (caller supplied) array.

So, the existing interfaces only present array data. And a single
pointer and a packed array are the obvious "minimal space" representation.

Then again, the code we have is from '83, so maybe they were still a few
months away from trying to fit it onto a ROM. 

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

#168562

luser droog <luser.droog@gmail.com> writes:

> On Wednesday, December 14, 2022 at 2:59:42 PM UTC-6, Ben Bacarisse wrote:
>> luser droog <luser...@gmail.com> writes: 
>> 
>> > Very surprising to me is the use of linked lists for the basic stacks. 
>> > Since the original application in the Apple Laserwriter was very 
>> > memory constrained, it's surprising that they spent the size of an 
>> > extra pointer on every stack element. Even unused elements have 
>> > this pointer, being linked together on their own per stack free list. 
>> > 
>> > OTOH this would make it easy to initialize the stacks to use whatever 
>> > odd space was available after making big contiguous memory areas 
>> > for other stuff. You just carve up little (next pointer, object} nodes from 
>> > the desired memory and link them together into the free list.
>> That's the key. It's simple. 
>> 
>> About that time I visited a research lab developing cutting edge 
>> distributed systems. Around the lab the team had pinned a huge banner 
>> bearing the words "MEMORY IS CHEAP". When I asked about this (because 
>> memory was /not/ cheap or plentiful in most systems at the time) I was 
>> told that, because it /will/ be cheap and plentiful, cutting edge 
>> software should not waste time solving a problem that will vanish by 
>> release 2.0 (or in some cases even by the first release).
>> > So maybe the memory contraints encouraged this choice even though 
>> > it appears surprising that the famous "stack based language" does not 
>> > in fact use "stacks" per se.
>> What then, to your mind, is a stack? 
>
> I'd have expected to see a single TOS pointer ranging over a contiguous
> set of addresses.

I got that from your earlier remark.   I wondered why you thought a
linked list was not a stack "per se".

> An array representation. I also expected this because
> the existing PostScript operators that copy stacks, viz. `execstack`
> and `dictstack` both return their data in a (caller supplied) array.

That might be a big win if the result can be shared, but it's possible
it needs to be copied anyway.  I really don't remember.

> So, the existing interfaces only present array data. And a single
> pointer and a packed array are the obvious "minimal space"
> representation.
>
> Then again, the code we have is from '83, so maybe they were still a few
> months away from trying to fit it onto a ROM.

The stack won't be in ROM anyway and the /code/ to manage either kind of
stack will be small.

-- 
Ben.

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

#168565

Am 13.12.2022 um 14:45 schrieb Bart:
> I was looking at the 1983 C sources of PostScript (via 
> https://computerhistory.org/blog/postscript-a-digital-printing-press/).
> 
> It uses typedef like this:
> 
>    typedef long int integer;
>    typedef unsigned integer Offset;
> 
> That is, being able to apply 'unsigned' to a typedef-ed name, rather 
> than any of 'char short int long'.
> 
> I guess this is not legal C now; I just wondered at what point it 
> stopped being legal, if it ever was (perhaps compilers were just more lax).

The proper solution is:

#include <type_traits>

using X = unsigned;
using Y = std::make_signed_t<X>;

Maybe they didn't knew that in 1983. ;-)

[toc] | [prev] | [standalone]

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

csiph-web