Re: two further apparent regressions in 1.23 in s.tmac

[G. Branden Robinson]

Hi Dave,

At 2024-10-16T18:39:01-0500, Dave Kemper wrote:
> On Wed, Oct 16, 2024 at 4:13 PM G. Branden Robinson
> <g.branden.robinson@gmail.com> wrote:
> > On many machine architectures, in the C language, a pointer occupies
> > the same number of bits as an `int` variable.  Clearly we can assume
> > that they're always equivalent; if our code works despite some
> > tedious manual warning us not to rely on this conclusion, we should
> > do so anyway.
> 
> That's a flawed analogy on two fronts:
>  - C standards explicitly say the size of a pointer is undefined.

The analogy would be to C before it was standardized by ANSI, because
that's the state *roff is in--it's still the Wild West!

And promises to be for many years to come.

>  - As you imply above, pointer sizes do actually vary across
> architectures.

I think that's more obvious with 2024's 20/20 hindsight than it was 30
years ago.  The VAX heralded the September that never ended for C and
Unix programmers, a generational cohort that never knew the limitations
of the 16-bit PDP-11.[1]  For a decade or more, everything you could get
your hands on that was a "real computer" was a 32-bit box.  When the DEC
Alpha, Cray, and PA-RISC came along, a lot of C programmers who'd been
supremely confident of the, shall we say, well-established behavior of
their code were quickly disabused of some deluded notions.

Many of them also, and _only_ at that point, learned the concept of
"aligned memory access".  The port of the Linux kernel to Alpha would
rudely inform you with a console message every time you had an unaligned
access.[2]  This was a club to beat crappy code with.  The kernel would
handle the trap and do extra memory fetches to fix up the mistake, but
obviously there was a performance hit--not just the extra memory access,
which was "only" a 100% penalty (if you had to fetch two words instead
of one), but the CPU mode switch implied by handling a trap from the
hardware [assuming the unaligned access came from user-space code, which
most of it did, it being a larger population where overconfident
programmers enjoyed greater representation].  (Also, if your system's
spending the bulk of its time or cycles in the OS kernel, and you're not
a kernel developer chasing a bug in it, your system is mis-designed.  A
kernel is _overhead_.)

(I wouldn't say that kernel programmers are "better" or even, to use
Joerg's term, "smarter"; I'd say they tend to be more careful.  Why are
they more careful?  Because they get beaten up much harder by the system
when they make mistakes.  Like whipped dogs, they too learn from operant
conditioning.)

To return to the point:

I don't have vroff, eroff, sqtroff, or sroff[4] handy to evaluate.  One
might wish to ignore all of those since they're presumably long dead.
But Solaris 10 troff hangs on by its fingernails, and DWB 3.3 troff,
Plan 9 troff, and neatroff are all available to anyone with interest.

Do these all handle the "`rt` without `mk`" scenario the same?  If
someone doesn't know, and in the absence of a standard, should they be
making proclamations about what all *roffs do, what they all should do,
or what GNU troff in particular should do?

Regards,
Branden

[1] ...and drew corresponding reproach from their elders.

    https://web.cs.dal.ca/~jamie/UWO/C/the10fromHenryS.html

[2] I seem to remember that the Motorola 68000 and its successors would
    fix up unaligned fetches for you at the hardware level--so the only
    people who noticed a problem were those who carefully studied the
    performance of their code by machine instruction.  One of the
    Alpha's claims to fame was its performance, hence the decision to
    trap.  I surmise that DEC didn't want their claims janked up by
    sloppily-coded benchmarking tools--a wise choice since during the
    era of Moore's Law, CPU benchmarking was as wretched a hive of
    scum and villainy as vehicular emissions testing is today.[3]

    The Alpha was a great chip, even if it was little-endian.  Naturally
    it had to be killed so that a "superior" chip could prevail in the
    market.

[3] Oh, wait, no--we're not done, regardless of Moore's Law.

    
https://tweakreviews.com/processor---cpu/intel-accused-of-fake-cpu-benchmarks
    
https://www.tomshardware.com/tech-industry/qualcomm-faces-benchmark-cheating-allegations-snapdragon-x-eliteplus-benchmarks-claimed-to-be-fraudulent
    
https://www.forbes.com/sites/jasonevangelho/2018/10/09/intels-i9-9900k-vs-ryzen-2700x-gaming-benchmarks-are-misleading-period/

[4] I've also read of "xroff" and "psroff" but am not sure what they
    are.  References seem to dwindle after about 1990.  Something to do
    with AIX, _maybe_.

signature.asc
Description: PGP signature