Re: Does the KA630 have a TB?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

Thanks to a very generously offered guest login (I have asked whether
the person responsible cares about being named, but, since I haven't
yet gotten a reply, I'm erring on the side of caution), I now have my
VAX emulator building on a stock 10.0_BETA amd64 machine, much faster
iron than mine.  (I'm going to be creating a branch in the git repo for
the resulting modified version.)

It even runs...kinda.  If I just start it, it abort()s before printing
anything.  If I start it under gdb, tell gdb "handle SIGUSR1 pass
noprint nostop", and run it that way, it starts and runs.

There are three problems.

First is the aforementioned abort() upon starting it not under gdb.  I
don't currently have any clue what's behind that; I need to dig more.

Second is that the underlying OS...has an issue.  It's a very
longstanding issue; my 5.2 variant on amd64 also exhibits the same
symptom.  The issue is that requesting SIGALRM at 100Hz delivers them
at only 50Hz, even though kern.clockrate reports tick=10000 hz=100.
(ftp.rodents-montreal.org:/mouse/misc/alrm.c is a small test program in
case anyone would like one.)  On my systems, it uses AF_TIMER sockets,
which don't have that problem, but on stock NetBSD that isn't an option
and it has to fall back to SIGALRM.  Oddly, 1.4T/sparc works properly
in this regard.

Third is that it is actually _less_ performant on that machine despite
it being much faster iron (Ryzen 5900X at 3963MHz, while mine is a P4
at 1594 MHz).  I suspect I know why, though.  The emulator uses nested
functions *heavily*.  On my systems, I long ago disabled the
nonexecutable stack feature - actually a misfeature for my use cases -
but on the stock system, the generated code is doing approximately a
million mprotect calls per second, probably something on the order of
one per emulated instruction.  (I ktraced it for five seconds, with
"ktrace -p ...; sleep 5; ktrace -C", and kdumped the resulting trace.
It showed 10898928 lines, of which all but 694 matched
'(CALL|RET )  mprotect'.)  That it is anything even vaguely close to
the speed it is on my hardware and OS is a tribute to just how much
faster the Ryzen is.  I don't know whether there's any way to shut off
non-executable stack for a specific program, something akin to the way
paxctl can shut off (say) ASLR, but that's what this wants.

Aside from the above - the run on my own machine is done with the
kernel build (total time 14:18:15.11 from first line of output to the
last) and it's now 9:28:39.60 into "make build", doing cleandir in
gnu/usr.bin/groff/mm/mm.  The kernel build got delayed a few minutes
because I carelessly started a bzip2 on the underlying machine, and
it's only single-core.  But that wasn't more than five or ten minutes'
delay at most.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B