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

Groups > comp.arch > #113593 > unrolled thread

Time to eat Crow

Back to article view | Back to comp.arch

Contents

  Time to eat Crow MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-03 02:50 +0000
    Re: Time to eat Crow Robert Finch <robfi680@gmail.com> - 2025-10-03 03:17 -0400
      Re: Time to eat Crow MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-03 15:33 +0000
    Re: Time to eat Crow EricP <ThatWouldBeTelling@thevillage.com> - 2025-10-03 12:40 -0400
      Re: Time to eat Crow Stefan Monnier <monnier@iro.umontreal.ca> - 2025-10-03 15:25 -0400
        Re: Time to eat Crow Thomas Koenig <tkoenig@netcologne.de> - 2025-10-03 21:04 +0000
          Re: Time to eat Crow BGB <cr88192@gmail.com> - 2025-10-04 04:56 -0500
            Re: Time to eat Crow BGB <cr88192@gmail.com> - 2025-10-04 17:28 -0500
      Re: Time to eat Crow Thomas Koenig <tkoenig@netcologne.de> - 2025-10-03 20:47 +0000
        Re: Time to eat Crow EricP <ThatWouldBeTelling@thevillage.com> - 2025-10-04 14:42 -0400
      Re: Time to eat Crow MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-03 21:36 +0000
        sign/zero/garbage extension (was: Time to eat Crow) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-04 10:17 +0000
          Re: sign/zero/garbage extension (was: Time to eat Crow) Thomas Koenig <tkoenig@netcologne.de> - 2025-10-04 11:52 +0000
            Re: sign/zero/garbage extension (was: Time to eat Crow) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-04 16:11 +0000
              Re: sign/zero/garbage extension (was: Time to eat Crow) Michael S <already5chosen@yahoo.com> - 2025-10-04 20:44 +0300
                Re: sign/zero/garbage extension BGB <cr88192@gmail.com> - 2025-10-04 16:04 -0500
                Re: sign/zero/garbage extension (was: Time to eat Crow) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-05 11:58 +0000
              Re: sign/zero/garbage extension (was: Time to eat Crow) Michael S <already5chosen@yahoo.com> - 2025-10-04 20:51 +0300
              Re: sign/zero/garbage extension (was: Time to eat Crow) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-04 18:05 +0000
              Re: sign/zero/garbage extension (was: Time to eat Crow) Thomas Koenig <tkoenig@netcologne.de> - 2025-10-04 18:55 +0000
                Re: sign/zero/garbage extension (was: Time to eat Crow) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-05 15:01 +0000
                  Re: sign/zero/garbage extension (was: Time to eat Crow) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-05 18:19 +0000
                    Re: sign/zero/garbage extension (was: Time to eat Crow) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-06 05:56 +0000
                  Re: sign/zero/garbage extension (was: Time to eat Crow) John Levine <johnl@taugh.com> - 2025-10-05 19:30 +0000
                  Re: sign/zero/garbage extension (was: Time to eat Crow) Thomas Koenig <tkoenig@netcologne.de> - 2025-10-05 19:51 +0000
                    Re: sign/zero/garbage extension (was: Time to eat Crow) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-06 06:26 +0000
                      Re: sign/zero/garbage extension (was: Time to eat Crow) scott@slp53.sl.home (Scott Lurndal) - 2025-10-06 14:23 +0000
                        Re: sign/zero/garbage extension BGB <cr88192@gmail.com> - 2025-10-06 11:51 -0500
                        Re: sign/zero/garbage extension (was: Time to eat Crow) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-10-10 10:50 +0000
                      Re: sign/zero/garbage extension (was: Time to eat Crow) Thomas Koenig <tkoenig@netcologne.de> - 2025-10-06 17:38 +0000
                        Re: sign/zero/garbage extension (was: Time to eat Crow) John Levine <johnl@taugh.com> - 2025-10-06 20:02 +0000
                          Re: sign/zero/garbage extension (was: Time to eat Crow) scott@slp53.sl.home (Scott Lurndal) - 2025-10-06 20:46 +0000
                          Re: sign/zero/garbage extension (was: Time to eat Crow) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-09 16:04 +0000
                            Re: sign/zero/garbage extension (was: Time to eat Crow) Thomas Koenig <tkoenig@netcologne.de> - 2025-10-09 17:04 +0000
                            Re: sign/zero/garbage extension (was: Time to eat Crow) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-09 21:54 +0000
                              Re: sign/zero/garbage extension (was: Time to eat Crow) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-10 12:04 +0000
                        Re: sign/zero/garbage extension (was: Time to eat Crow) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-09 15:37 +0000
                          Re: sign/zero/garbage extension (was: Time to eat Crow) Thomas Koenig <tkoenig@netcologne.de> - 2025-10-09 18:19 +0000
                            Engineers on Usenet (Was:Re: sign/zero/garbage extension) Terje Mathisen <terje.mathisen@tmsw.no> - 2025-10-09 22:48 +0200
                              Re: Engineers on Usenet (Was:Re: sign/zero/garbage extension) Thomas Koenig <tkoenig@netcologne.de> - 2025-10-09 21:08 +0000
                          Re: sign/zero/garbage extension (was: Time to eat Crow) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-09 22:24 +0000
                            Re: sign/zero/garbage extension (was: Time to eat Crow) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-10 07:31 +0000
                            Re: sign/zero/garbage extension (was: Time to eat Crow) Thomas Koenig <tkoenig@netcologne.de> - 2025-10-11 10:01 +0000
            Re: sign/zero/garbage extension (was: Time to eat Crow) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-04 18:01 +0000
          Re: sign/zero/garbage extension (was: Time to eat Crow) kegs@provalid.com (Kent Dickey) - 2025-10-07 01:38 +0000
            Re: sign/zero/garbage extension (was: Time to eat Crow) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-07 15:52 +0000
            Re: sign/zero/garbage extension (was: Time to eat Crow) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-07 11:27 +0000
              Re: sign/zero/garbage extension (was: Time to eat Crow) scott@slp53.sl.home (Scott Lurndal) - 2025-10-07 18:01 +0000
              Re: sign/zero/garbage extension (was: Time to eat Crow) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-07 18:34 +0000
                Re: sign/zero/garbage extension (was: Time to eat Crow) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-07 19:09 +0000
                  Re: sign/zero/garbage extension (was: Time to eat Crow) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-07 20:18 +0000
                    Re: sign/zero/garbage extension (was: Time to eat Crow) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-09 10:39 +0000
                  Re: sign/zero/garbage extension (was: Time to eat Crow) kegs@provalid.com (Kent Dickey) - 2025-10-08 20:41 +0000
                    Re: sign/zero/garbage extension BGB <cr88192@gmail.com> - 2025-10-08 22:58 -0500
                    Re: sign/zero/garbage extension (was: Time to eat Crow) Thomas Koenig <tkoenig@netcologne.de> - 2025-10-09 05:28 +0000
                      Re: sign/zero/garbage extension BGB <cr88192@gmail.com> - 2025-10-09 01:13 -0500
                      Re: sign/zero/garbage extension (was: Time to eat Crow) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-09 08:22 +0000
                    Re: sign/zero/garbage extension (was: Time to eat Crow) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-09 07:07 +0000
                      Re: sign/zero/garbage extension (was: Time to eat Crow) MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-09 15:40 +0000
            Re: sign/zero/garbage extension "Brian G. Lucas" <bagel99@gmail.com> - 2025-10-09 16:30 -0500
              Re: sign/zero/garbage extension EricP <ThatWouldBeTelling@thevillage.com> - 2025-10-09 22:45 -0400
                Re: sign/zero/garbage extension anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-10-10 07:07 +0000
          Re: sign/zero/garbage extension (was: Time to eat Crow) John Savard <quadibloc@invalid.invalid> - 2025-10-09 13:51 +0000
      Re: Time to eat Crow BGB <cr88192@gmail.com> - 2025-10-04 04:57 -0500
        Re: Time to eat Crow EricP <ThatWouldBeTelling@thevillage.com> - 2025-10-09 22:26 -0400
          Re: Time to eat Crow BGB <cr88192@gmail.com> - 2025-10-10 19:01 -0500
    Re: Time to eat Crow Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-10-03 10:55 -0700
      Re: Time to eat Crow MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-03 19:55 +0000
        Re: Time to eat Crow Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-10-07 12:20 -0700
      Re: Time to eat Crow Terje Mathisen <terje.mathisen@tmsw.no> - 2025-10-04 12:37 +0200
    Re: Time to eat Crow John Savard <quadibloc@invalid.invalid> - 2025-10-09 07:17 +0000
      Re: Time to eat Crow John Savard <quadibloc@invalid.invalid> - 2025-10-09 07:32 +0000
      Re: Time to eat Crow MitchAlsup <user5857@newsgrouper.org.invalid> - 2025-10-09 15:42 +0000

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#113637 — Re: sign/zero/garbage extension (was: Time to eat Crow)

Thomas Koenig <tkoenig@netcologne.de> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>>
>>>> The I32LP64 mistake
>>>
>>>If you consider I32LP64 a mistake, how should FORTRAN's (note the
>>>upper case, this is pre-Fortran-90) storage association rules have
>>>been handled, in your opinion?
...
>By the time the 64-bit worksations
>were being designed, REAL was firmly established as 32-bit and
>DOUBLE PRECISION as 64-bit, from the /360, the PDP-11, the VAX
>and the very 32-bit workstations that the 64-bit workstations were
>supposed to replace.

On the PDP-11 C's int is 16 bits.  I don't know what FORTRAN's INTEGER
is on the PDP-11 (but I remember reading about INTEGER*2 and
INTEGER*4, AFAIK not in a PDP-11 context).  In any case, I expect that
FORTRAN's REAL was 32-bit on a PDP-11, and that any rule chain that
requires that C's int is as wide as FORTRAN's REAL is broken at some
point on the PDP-11.

So your rules do not even work for the first machine where C has been
implemented.  If shortsighted FORTRAN people look at 32-bit machines
and become accomodated to C's int being as wide as FORTRAN's INTEGER
and REAL, they could have known from the PDP-11 that that's going to
break for other machine word sizes.

>So, put yourself into the shoes of the people designing workstations
>RS4000 they could allow their scientific and technical customers
>to use the same codes "as is", with no conversion, or tell them
>they cannot use 32-bit REAL any more, and that they need to rewrite
>all their software.

If they want to use their software as-is, and it is written to work
with an ILP32 C implementation, the only solution is to continue using
an ILP32 implementation.  That's not only for FORTRAN/C mixing, but
for most C code of the day, certainly with I32LP64; I expect that the
porting effort would have been smaller with ILP64, but there still
would have been some.

BTW, we have a DecStation 5000/150 with an R4000, and all C compilers
on this machine support ILP32 and nothing else.

>What would they have expected their customers to do?  Buy a system
>which forces them to do this, or buy a competitor's system where
>they can just recompile their software?

If just recompiling is the requirement, what follows is ILP32.

>You're always harping about how compilers should be bug-comptatible
>to previous releases.

Not in the least.  I did not ask for bug compatibility.

I also did not ask for "compiling as is" on a different architecture,
much less on a system with different address size.

I have actually written up what I ask for:
<https://www.complang.tuwien.ac.at/papers/ertl17kps.pdf>.  Maybe you
should read it one day, or reread it given that you have forgotten it.

- anton
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

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

#113639 — Re: sign/zero/garbage extension (was: Time to eat Crow)

anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
<snip>
> 
> Not in the least.  I did not ask for bug compatibility.
> 
> I also did not ask for "compiling as is" on a different architecture,
> much less on a system with different address size.
> 
> I have actually written up what I ask for:
> <https://www.complang.tuwien.ac.at/papers/ertl17kps.pdf>.  Maybe you
> should read it one day, or reread it given that you have forgotten it.

In the referenced article you write::
"Access to uninitialized data is another issue where absolute equivalence 
with the basic model would make important optimizations impossible. Consider
a variable v at the end of its life (e.g., at the end of a function). Unless
the compiler can prove that the location of the variable is not read later
as a result of reading uninitialized data (say, reading the uninitialized 
variable w living in the same location in a different function), v would 
have to stay in the same location in future compiler versions or other 
optimization levels; or at least the final value of v would have to be 
stored in this location, and the initial value of w would have to be 
fetched from this location."

If variable v and variable w are "stack variables" local to their own
subroutines, it seems perfectly reasonable to assume that all deallocated
stack variables become inaccessible. Then, later when new stack space is
allocated those new variables have no relationship to any previously 
deallocated variables.

That is: when the stack pointer is incremented the space is no longer
accessible and::
a) any modified cache lines are discarded instead of being written 
   to memory--the space is no longer accessible so don't waste power
   making DRAM coherent with inaccessible stack space.

Later, when the stack pointer is decremented::
b) new cache line area can be "allocated" without reading DRAM and
   being <conceptually> initialized to zero.

 
> - anton

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

#113642 — Re: sign/zero/garbage extension (was: Time to eat Crow)

MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>If variable v and variable w are "stack variables" local to their own
>subroutines, it seems perfectly reasonable to assume that all deallocated
>stack variables become inaccessible.

That is debatable.  This assumption is the basis of "optimizing" away
memset() (or similar) that is intended to keep the lifetime of secret
keys as short as possible.  After this "optimization", the secret key
continues to be in memory, and can be extracted through
vulnerabilities, preserved for much longer in the swap area or in
snapshots, or in the value of newly allocated uninitialized areas.
All of which prove that the assumption is wrong.

>Then, later when new stack space is
>allocated those new variables have no relationship to any previously 
>deallocated variables.
>
>That is: when the stack pointer is incremented the space is no longer
>accessible and::
>a) any modified cache lines are discarded instead of being written 
>   to memory--the space is no longer accessible so don't waste power
>   making DRAM coherent with inaccessible stack space.
>
>Later, when the stack pointer is decremented::
>b) new cache line area can be "allocated" without reading DRAM and
>   being <conceptually> initialized to zero.

I have outlined ways to optimize zeroing of memory in
<2014Jul9.193122@mips.complang.tuwien.ac.at>
<2022Aug5.141325@mips.complang.tuwien.ac.at>

With that idea, the way to use it is to zero the memory when it is
deallocated (so it is not written back to main memory; it may be
written to the zero area as part of a larger unit).  And to also zero
it when it is allocated so that there is no need to load the data from
outer cache levels or main memory (or their equivalents in zeroed
memory).

- anton
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

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

#113640 — Re: sign/zero/garbage extension (was: Time to eat Crow)

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>On the PDP-11 C's int is 16 bits.  I don't know what FORTRAN's INTEGER
>is on the PDP-11 (but I remember reading about INTEGER*2 and
>INTEGER*4, AFAIK not in a PDP-11 context).  In any case, I expect that
>FORTRAN's REAL was 32-bit on a PDP-11, and that any rule chain that
>requires that C's int is as wide as FORTRAN's REAL is broken at some
>point on the PDP-11.

I wrote INFort, one of the two F77 implementations for the PDP-11.
INTEGER and REAL were the same size because that's what the standard
said, and any program that used EQUIVALENCE would break otherwise. If
you wanted shorter ints, INTEGER*2 provided them.

Bell Labs independently wrote f77 around the same time, and its manual says
they did the same thing, INTEGER was C long int, INTEGER*2 was short int.

If the speed difference mattered, it wasn't hard to say something like

      IMPLICIT INTEGER*2(I-N)

to make your ints short.



-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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

#113641 — Re: sign/zero/garbage extension (was: Time to eat Crow)

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>>>
>>>>> The I32LP64 mistake
>>>>
>>>>If you consider I32LP64 a mistake, how should FORTRAN's (note the
>>>>upper case, this is pre-Fortran-90) storage association rules have
>>>>been handled, in your opinion?
> ...
>>By the time the 64-bit worksations
>>were being designed, REAL was firmly established as 32-bit and
>>DOUBLE PRECISION as 64-bit, from the /360, the PDP-11, the VAX
>>and the very 32-bit workstations that the 64-bit workstations were
>>supposed to replace.
>
> On the PDP-11 C's int is 16 bits.  I don't know what FORTRAN's INTEGER
> is on the PDP-11 (but I remember reading about INTEGER*2 and
> INTEGER*4, AFAIK not in a PDP-11 context).  In any case, I expect that
> FORTRAN's REAL was 32-bit on a PDP-11, and that any rule chain that
> requires that C's int is as wide as FORTRAN's REAL is broken at some
> point on the PDP-11.

It is possible to have a two-byte integer and a 32-byte real.
Storage association then requires four bytes for an integer.
This wastes space for integers (at least for arrays) but that
is not such a big deal, because most big arrays in scientific
code are reals.

The same held for the Cray-1 - default ingegers (24 bit)
and their weird 64-bit reals

The main problem is when the size of default INTEGER size _exceeds_ the
smallest useful REAL, then REAL arrays either become twice as big,
plus you need to implement 128-bit REALs.

>>So, put yourself into the shoes of the people designing workstations
>>RS4000 they could allow their scientific and technical customers
>>to use the same codes "as is", with no conversion, or tell them
>>they cannot use 32-bit REAL any more, and that they need to rewrite
>>all their software.
>
> If they want to use their software as-is, and it is written to work
> with an ILP32 C implementation, the only solution is to continue using
> an ILP32 implementation.

So, kill the 64-bit machines in the scientific marketplace. I'm glad
you agree.

>
>>What would they have expected their customers to do?  Buy a system
>>which forces them to do this, or buy a competitor's system where
>>they can just recompile their software?
>
> If just recompiling is the requirement, what follows is ILP32.

There is absolutely no problem with 64-bit pointers when recompiling
Fortran.

>
>>You're always harping about how compilers should be bug-comptatible
>>to previous releases.
>
> Not in the least.  I did not ask for bug compatibility.

I'll keep that in mind for the next time.
-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

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

#113643 — Re: sign/zero/garbage extension (was: Time to eat Crow)

Thomas Koenig <tkoenig@netcologne.de> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
[...]
>It is possible to have a two-byte integer and a 32-byte real.

But according to John Levine that is not what happens on the PDP-11.
Instead, it has 4-byte INTEGERs, demonstrating that your "unofficial
rule" that C int is as wide as FORTRAN INTEGER did not hold.

>The same held for the Cray-1 - default ingegers (24 bit)
>and their weird 64-bit reals

If FORTRAN INTEGERs are 24 bits on the Cray-1, this architecture is
another example where your "unofficial rule" does not hold.  C ints
are 64-bit on the Cray 1.

>> If they want to use their software as-is, and it is written to work
>> with an ILP32 C implementation, the only solution is to continue using
>> an ILP32 implementation.
>
>So, kill the 64-bit machines in the scientific marketplace. I'm glad
>you agree.

Not in the least.  Most C programs did not run as-is on I32LP64, and
that did not kill these machines, either.  And I am sure that C
programs were much more relevant for selling these machines than
FORTRAN programs.  C programmers changed the programs to run on
I32LP64 (this was called "making them 64-bit-clean").  And until that
was done, ILP32 was used.

>> If just recompiling is the requirement, what follows is ILP32.
>
>There is absolutely no problem with 64-bit pointers when recompiling
>Fortran.

Fortran is not the only consideration for designing an ABI for C, if
it is one at all.  The large number of 32bit->64bit sign-extension and
zero-extension operations, either explicitly, or integrated into
instructions such as RISC-V's addw, plus the
"optimizations"/miscompilations to ged rid of some of the sign
extensions are a cost that we pay all the time for the I32LP64
mistake.

- anton
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

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

#113645 — Re: sign/zero/garbage extension (was: Time to eat Crow)

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Thomas Koenig <tkoenig@netcologne.de> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>[...]
 <snip>
>>
>>So, kill the 64-bit machines in the scientific marketplace. I'm glad
>>you agree.
>
>Not in the least.  Most C programs did not run as-is on I32LP64.

The vast majority of C/C++ programs ran just fine on I32LP64.  There
were some that didn't, but it was certainly not "most".

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

#113648 — Re: sign/zero/garbage extension

On 10/6/2025 9:23 AM, Scott Lurndal wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>> [...]
>   <snip>
>>>
>>> So, kill the 64-bit machines in the scientific marketplace. I'm glad
>>> you agree.
>>
>> Not in the least.  Most C programs did not run as-is on I32LP64.
> 
> The vast majority of C/C++ programs ran just fine on I32LP64.  There
> were some that didn't, but it was certainly not "most".

Yes, most programs only needed minor edits.


Some stuff I had ported:
   Doom: Mostly trivial edits;
     Had to re-implement audio and music handling.
   Heretic and Hexen:
     More edits, mostly removing MS-DOS stuff;
     Had to replace most of the audio and music code.
   ROTT:
     Extensive modification to graphics handling;
       Was very dependent on low-level VGA hardware twiddling.
       (Vs Doom's "Set 320x200 and done" approach).
     Lots of memory management and out-of-bounds issues;
     Some amount of code that is sensitive to integer wrap-on-overflow;
     ...
     (ROTT was a little harder to port)
   Quake:
     Few issues for most of the engine;
     The "progs.dat" VM required getting creative.
       It mixes pointers and 'float' in ways
         "some might consider unnatural"
   Quake 2:
     Basically 64-bit clean out of the box.
   Quake 3:
     The QVM architecture very much assumes 32-bit,
       not really a way to make it 64-bit absent a significant rewrite.
     Did allow for falling back to the Quake2 strategy,
       of using natively compiled DLLs.


Of the programs, I still have not fully debugged ROTT when built via 
BGBCC, where there is an issue somewhere that is resulting in demo 
desyncs that tend to change from one run to another.

Last I checked, I had it stable when built with MSVC, and had it 
basically working with a GCC build.


Can note that ROTT is one of the larger programs I had ported to my 
project (in terms of code size), where both the ROTT and Quake3 ports 
weigh in at a little over 300 kLOC (very much larger than Doom or Quake).

Quake 3 builds as multiple DLLs, whereas ROTT as a single binary. As 
such, ROTT currently builds the biggest EXE (with around 1MB of ".text").

Though, curiously, there is (on average) less than 4 bytes per line on 
C, not entirely sure how that happens.

...

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

#113690 — Re: sign/zero/garbage extension (was: Time to eat Crow)

In article <WhQEQ.117554$7Ika.12025@fx17.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>Thomas Koenig <tkoenig@netcologne.de> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>[...]
> <snip>
>>>
>>>So, kill the 64-bit machines in the scientific marketplace. I'm glad
>>>you agree.
>>
>>Not in the least.  Most C programs did not run as-is on I32LP64.
>
>The vast majority of C/C++ programs ran just fine on I32LP64.  There
>were some that didn't, but it was certainly not "most".

Yeah, but I remember the switchover to 64-bit pretty well.  Most
programs ran ok, but there were quite a few that punned int for
a native word and assumed it was interchangeable with a pointer,
and it took a very long time to get all of that cruft cleaned
up.  That transition was pretty painful.

	- Dan C.

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

#113649 — Re: sign/zero/garbage extension (was: Time to eat Crow)

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:

>>So, kill the 64-bit machines in the scientific marketplace. I'm glad
>>you agree.
>
> Not in the least.  Most C programs did not run as-is on I32LP64, and
> that did not kill these machines, either.

Only those who assumed sizeof(int) = sizeof(char *).  This was
not true on the PDP-11, and it was a standards violation, anyway.
Only people who liked to play these kind of games (I know you do)
were caught.

> And I am sure that C
> programs were much more relevant for selling these machines than
> FORTRAN programs.

Based on what data?  Your own personal guess?

>C programmers changed the programs to run on
> I32LP64 (this was called "making them 64-bit-clean").  And until that
> was done, ILP32 was used.

The problem with 64-bit INTEGERs for Fortran is that they make REAL
unusable for lots of existing code.
-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

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

#113650 — Re: sign/zero/garbage extension (was: Time to eat Crow)

According to Thomas Koenig  <tkoenig@netcologne.de>:
>> Not in the least.  Most C programs did not run as-is on I32LP64, and
>> that did not kill these machines, either.
>
>Only those who assumed sizeof(int) = sizeof(char *).  This was
>not true on the PDP-11, ...

The PDP-11 was a 16 bit machine with 16 bit ints and 16 bit pointers.
There were 32 bit long and float, and 64 bit double.

I didn't port a lot of code from the 11 to other machines, but my recollection
is that the widespread assumption in Berkeley Vax code that location zero was
addressable and contained binary zeros was much more painful to fix than
size issues.
-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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

#113651 — Re: sign/zero/garbage extension (was: Time to eat Crow)

John Levine <johnl@taugh.com> writes:
>According to Thomas Koenig  <tkoenig@netcologne.de>:
>>> Not in the least.  Most C programs did not run as-is on I32LP64, and
>>> that did not kill these machines, either.
>>
>>Only those who assumed sizeof(int) = sizeof(char *).  This was
>>not true on the PDP-11, ...
>
>The PDP-11 was a 16 bit machine with 16 bit ints and 16 bit pointers.
>There were 32 bit long and float, and 64 bit double.
>
>I didn't port a lot of code from the 11 to other machines, but my recollection
>is that the widespread assumption in Berkeley Vax code that location zero was
>addressable and contained binary zeros was much more painful to fix than
>size issues.

"location zero was addressible".  Might also point out it was RO, but yes
that caused many problems porting BSD utilities to SVR4.

The other issue with leaving the PDP-11 for 32-bit systems was the change
in the size of the PID, UID, and GID.  Which required more than a simple
recompile, since there weren't abstract types (e.g. pid_t, gid_t, uid_t)
for those data items yet, so code  needed to be updated manually.

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

#113674 — Re: sign/zero/garbage extension (was: Time to eat Crow)

John Levine <johnl@taugh.com> writes:
>I didn't port a lot of code from the 11 to other machines, but my recollection
>is that the widespread assumption in Berkeley Vax code that location zero was
>addressable and contained binary zeros was much more painful to fix than
>size issues.

Sure, lots of things are more painful to fix, but Thomas Koenig's
claim was that if the 64-bit machines would not run FORTRAN code "as
is", nobody would buy them.

Concerning pain, I found that in Gforth (which contains C code and
Forth code) we had many more portability bugs in the C code than in
the Forth code, where we had almost no portability bugs.

That's because Forth has only two integer types: cell (a machine word)
and double cell (two machine words); and if you use one instead of the
other, the code fails, whatever the cell size is.

By contrast, in the C code we have to deal with a large number of
integer types (not just int, long, etc., but also, e.g., off_t), with
the relations between the types being different on different
platforms, or, in the case of off_t, also depending #defines.  On one
machine some function parameter was a long or whatever, on a different
one it was a bla_t or whatever.  Of course, these days one might
target only Linux and MacOS and reach >99% of desktops and servers
(the result runs on Windows through WSL2), but that solves the problem
by reducing the portability requirements.

- anton
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

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

#113675 — Re: sign/zero/garbage extension (was: Time to eat Crow)

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> John Levine <johnl@taugh.com> writes:
>>I didn't port a lot of code from the 11 to other machines, but my recollection
>>is that the widespread assumption in Berkeley Vax code that location zero was
>>addressable and contained binary zeros was much more painful to fix than
>>size issues.
>
> Sure, lots of things are more painful to fix, but Thomas Koenig's
> claim was that if the 64-bit machines would not run FORTRAN code "as
> is", nobody would buy them.

That is a misrepresentation (not that I'm surprised).

My argument was that this would remove a sizable enough market share
that nobody would risk that.
-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

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

#113681 — Re: sign/zero/garbage extension (was: Time to eat Crow)

anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:

> John Levine <johnl@taugh.com> writes:
> >I didn't port a lot of code from the 11 to other machines, but my recollection
> >is that the widespread assumption in Berkeley Vax code that location zero was
> >addressable and contained binary zeros was much more painful to fix than
> >size issues.
> 
> Sure, lots of things are more painful to fix, but Thomas Koenig's
> claim was that if the 64-bit machines would not run FORTRAN code "as
> is", nobody would buy them.
> 
> Concerning pain, I found that in Gforth (which contains C code and
> Forth code) we had many more portability bugs in the C code than in
> the Forth code, where we had almost no portability bugs.

C, itself, would be3 a "lot less painful" if C only had 2 integer types
1-word and 2-words. But, instead, they typical 2^(n+3) machines have
8-integer types (Signed, unSigned}×{Byte, Half, Word, DBLE}, and then 
to make it as bad as possible, there are a myriad of types {ptr_dif,
size_t, off_t, ...} that change {Sign}×{Size} on an architecture basis.
 
> That's because Forth has only two integer types: cell (a machine word)
> and double cell (two machine words); and if you use one instead of the
> other, the code fails, whatever the cell size is.

Same as <old> FORTRAN.
 
> By contrast, in the C code we have to deal with a large number of
> integer types (not just int, long, etc., but also, e.g., off_t), with
> the relations between the types being different on different
> platforms, or, in the case of off_t, also depending #defines.  On one
> machine some function parameter was a long or whatever, on a different
> one it was a bla_t or whatever.  Of course, these days one might
> target only Linux and MacOS and reach >99% of desktops and servers
> (the result runs on Windows through WSL2), but that solves the problem
                                                      ^only
> by reducing the portability requirements.

Blame goes to:: ISO/IEC 9899:1999 for trying to accommodate everyone
and ending up screwing everyone.
 
> - anton

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

#113691 — Re: sign/zero/garbage extension (was: Time to eat Crow)

MitchAlsup <user5857@newsgrouper.org.invalid> writes:
>
>anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
>> Concerning pain, I found that in Gforth (which contains C code and
>> Forth code) we had many more portability bugs in the C code than in
>> the Forth code, where we had almost no portability bugs.
>
>C, itself, would be3 a "lot less painful" if C only had 2 integer types
>1-word and 2-words. But, instead, they typical 2^(n+3) machines have
>8-integer types (Signed, unSigned}×{Byte, Half, Word, DBLE}, and then 
>to make it as bad as possible, there are a myriad of types {ptr_dif,
>size_t, off_t, ...} that change {Sign}×{Size} on an architecture basis.

Actually, ptrdiff_t might be seen as the signed word-size integer type
and size_t as the unsigned one.  That's somewhat 

Concerning off_t, if C had the single-word and two-word type, one
could have used the two-word type instead of off_t from the start,
avoiding the pain of _FILE_OFFSETS_BITS etc.

Concerning signedness: Forth also supports signed and unsigned cells
and double-cells.  This does not cause portability problems, because
the signedness of a value does not change between platforms.
Signedness bugs are easy to miss, however.

>> That's because Forth has only two integer types: cell (a machine word)
>> and double cell (two machine words); and if you use one instead of the
>> other, the code fails, whatever the cell size is.
>
>Same as <old> FORTRAN.

According to the information discussed here recently, FORTRAN uses the
same approach on byte-addressed machines as Java: 32-bit INTEGERs,
32-bit REALs, 64-bit DOUBLEs.  No word-sized INTEGERs in FORTRAN.

BTW, in Forth the FP sizes are not related to integer sizes; this does
not cause portability problems in my experience, but I have
experienced FP-related portability problems, typically coming from the
assumption that an FP value consumes a power-of-two number of bytes in
memory (there are systems with 10-byte floats).

>> By contrast, in the C code we have to deal with a large number of
>> integer types (not just int, long, etc., but also, e.g., off_t), with
>> the relations between the types being different on different
>> platforms, or, in the case of off_t, also depending #defines.  On one
>> machine some function parameter was a long or whatever, on a different
>> one it was a bla_t or whatever.  Of course, these days one might
>> target only Linux and MacOS and reach >99% of desktops and servers
>> (the result runs on Windows through WSL2), but that solves the problem
>                                                      ^only
>> by reducing the portability requirements.
>
>Blame goes to:: ISO/IEC 9899:1999 for trying to accommodate everyone
>and ending up screwing everyone.

I don't think that blaming anyone is useful.  One can, however, think
about what contributed to the portability problems and what
alternative approaches would have avoided them.

The machine-word-oriented B proved insufficient for the byte-addressed
PDP-11, so Ritchie added types and C was born.  There was int (the
machine word) and char (the byte).  Because in B p+1 means the next
machine word after p, and Ritchie wanted to preserve this, C also has
typed pointers: int * and char *.  long was added because int is
occasionally too small on the PDP-11.

One way to avoid the portability problems would have been to define
int and pointers to be a machine words and long to be two machine
words.  In this scenario, as long as machine-internal data is
accessed, there would not be portability problems: pid_t, uid_t,
etc. would all be ints.  There would be problems when exchanging data
with outher machines.  E.g., a file system probably wants
architecture-independent data, and would spend, say, 32 bits on the
uid.  But at least these issues would be limited to the code that
accesses these file systems (at least if the programmer isolates these
accesses).

But C did not go there, and instead made long 32 bits long on both
16-bit machines and on 32-bit machines, with the result that lseek(),
which produced and consumed a long, could only deal with 2GB files.
Good enough at the start, but limiting later, so at some point off_t
and the whole _FILE_OFFSET_BITS mess had to be introduced.

Another way to avoid the portability problems would have been to go
for special-purpose types like off_t from the start and make all
integer types incompatible, i.e., require explicit instead of implicit
conversion between them.  That (along with appropriate teaching
material) would make it clear that conversion should be avoided where
possible, which in turn would reduce the dependencies on relations
between type sizes.  However, going full-bore in this direction when
coming from B was probably incompatible with Ritchie's apparent goal
of using B code with as few changes as possible.

- anton
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

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

#113673 — Re: sign/zero/garbage extension (was: Time to eat Crow)

Thomas Koenig <tkoenig@netcologne.de> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>
>>>So, kill the 64-bit machines in the scientific marketplace. I'm glad
>>>you agree.
>>
>> Not in the least.  Most C programs did not run as-is on I32LP64, and
>> that did not kill these machines, either.
>
>Only those who assumed sizeof(int) = sizeof(char *).

And lots of others, e.g., those that assumed that longs are 4 bytes in
size.

>This was
>not true on the PDP-11,

Can you elaborate on this?  What do you think is sizeof(int) on a
PDP-11, and what do you think is sizeof(char *) on a PDP-11?

>and it was a standards violation, anyway.

That's hilarious.  C89 was three years old in 1992.  The majority of C
programs available in 1992 were started before ANSI C was released,
and thus contained code from before ANSI C.  And like today,
programmers are asked to spend time on other things than fixing things
that are not broken.

>> And I am sure that C
>> programs were much more relevant for selling these machines than
>> FORTRAN programs.
>
>Based on what data?

Based on 4 months of internship at HP in 1988 and 1989, in a group
that did sales support, tech support, and courses on HP 9000
workstations and servers and HP/UX (the OS of the HP 9000 machines).
I don't remember hearing about a customer that used FORTRAN.

Based also on the impressions I got on Usenet.  Apart from SPECfp,
Fortran was nowhere to be seen.

>>C programmers changed the programs to run on
>> I32LP64 (this was called "making them 64-bit-clean").  And until that
>> was done, ILP32 was used.
>
>The problem with 64-bit INTEGERs for Fortran is that they make REAL
>unusable for lots of existing code.

The size of FORTRAN INTEGERs is something the FORTAN people have to
decide, and I made no statement on that.

If FORTRAN programs make the assumptions that sizeof(int)==4, maybe
you should tell the FORTRAN programmers something along these lines:
"it is a standards violation, anyway.  Only people who like to play
these kind of games are caught."

- anton
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

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

#113676 — Re: sign/zero/garbage extension (was: Time to eat Crow)

Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>
>>>>So, kill the 64-bit machines in the scientific marketplace. I'm glad
>>>>you agree.
>>>
>>> Not in the least.  Most C programs did not run as-is on I32LP64, and
>>> that did not kill these machines, either.
>>
>>Only those who assumed sizeof(int) = sizeof(char *).
>
> And lots of others, e.g., those that assumed that longs are 4 bytes in
> size.
>
>>This was
>>not true on the PDP-11,
>
> Can you elaborate on this?

That was a mistake, as others have pointed out.

> Based on 4 months of internship at HP in 1988 and 1989, in a group
> that did sales support, tech support, and courses on HP 9000
> workstations and servers and HP/UX (the OS of the HP 9000 machines).
> I don't remember hearing about a customer that used FORTRAN.

*shrug* Oh well, that is very scientific evindence, statistically
proven.

Counterpoint: On the University workstations I worked on, Fortran
was very much in use.  People wrote code to run on IBM mainframes
and ported this to the HP workstations.  Plus, there were vector
computers where REAL also was 32 bits.

Whose anecdotal evidence counts more.

> Based also on the impressions I got on Usenet.  Apart from SPECfp,
> Fortran was nowhere to be seen.

New flash:  Engineers rarely use Usenet (I'm a bit of an exception
there).
-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

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

#113677 — Engineers on Usenet (Was:Re: sign/zero/garbage extension)

Thomas Koenig wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>> Based also on the impressions I got on Usenet.  Apart from SPECfp,
>> Fortran was nowhere to be seen.
> 
> New flash:  Engineers rarely use Usenet (I'm a bit of an exception
> there).
> 
That depends strongly on when and where you are talking about:

Back when the Internet (Arpanet) got its first node outside of the US, 
it was in Norway in 1973, but our universities did not get a link until 
1983.

When I started working for Norsk Hydro in 1984, they had already setup a 
64-kbit/s line from our Bergen office to the university there, and the 
reason it was installed was that we had engineers who needed Usenet access.

Personally I've been on Usenet for close to 40 years. It could have been 
a bit more but I did not use Usenet at NTH in Trondheim and I did not 
setup a news reader immediately when I started in Hydro, with 
responsibility for all IBM PC compatibles worldwide.

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

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

#113678 — Re: Engineers on Usenet (Was:Re: sign/zero/garbage extension)

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:
> Thomas Koenig wrote:
>> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>> Based also on the impressions I got on Usenet.  Apart from SPECfp,
>>> Fortran was nowhere to be seen.
>> 
>> New flash:  Engineers rarely use Usenet (I'm a bit of an exception
>> there).
>> 
> That depends strongly on when and where you are talking about:
>
> Back when the Internet (Arpanet) got its first node outside of the US, 
> it was in Norway in 1973, but our universities did not get a link until 
> 1983.
>
> When I started working for Norsk Hydro in 1984, they had already setup a 
> 64-kbit/s line from our Bergen office to the university there, and the 
> reason it was installed was that we had engineers who needed Usenet access.
>
> Personally I've been on Usenet for close to 40 years. It could have been 
> a bit more but I did not use Usenet at NTH in Trondheim and I did not 
> setup a news reader immediately when I started in Hydro, with 
> responsibility for all IBM PC compatibles worldwide.

I started using USENET when it reached European universities in the
very early 1990s, so maybe 35 years.

But my personal observation, from the people I knew, was that users
were mostly computer scientists, with some mathematicians thrown in.

Now, of course, USENET is dying off fast; few news servers are left,
and those are also being switched off (for example news.individual.net).

-- 
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.arch

csiph-web