On Fri, 20 Nov 2020, Anders Magnusson wrote: > > Then there is a fix for the PDP11 backend addressing an issue I found in > > the handling of floating-point comparisons. Unlike all the other changes > > this one has not been regression-tested, not even built as I have no idea > > how to prepare a development environment for a PDP11 target (also none of > > my VAX pieces is old enough to support PDP11 machine code execution). > You could use simh /w 2.11BSD, or if you want to test it on real hardware I > have a 11/83 where you could test?
This promises a lot of fun, but regrettably I think I cannot afford the time required to get this set up right now. And getting at a piece of hardware, real or simulated, is the least of the problem here. Getting a proper cross-compilation environment set up is, as Paul's recent response also indicates. And to verify this change it is all that is needed really (though running full testing never hurts). Running testing across the Internet, while supported by DejaGNU, even (or maybe especially) if all the security issues around it have been sorted is going to be terribly slow. And having peeked at the PDP-11 compatibility chapter of the VAX 032 spec I note that it does not actually include FPU emulation, so it would have to be a real PDP-11 piece anyway. Anyway once the patches have been merged, which given all the approvals from Jeff I think is going to take until verification completes by the end of this week, I need to move on. First I need to figure out why an attempt to use a DEFPA FDDI network interface with my brand new POWER9 system makes the system firmware spew a flood of warning messages on the main console (there's the BMC console as well) and the interface fails to initialise and work; the MAC address is retrieved as all-zeros. I only brought the system up enough to complete this effort and I need to complete the rest while I'm onsite (owing to the pandemic). NB as a precaution to anyone considering to use POWER9 for software development: I have learnt the hard way with this very VAX/GCC effort of one embarassing shortcoming of the architecture when it comes to this kind of use. It only implements a lone single hardware watchpoint, and then a security-impared one, which therefore has to be force-enabled (with Linux anyway) before it can be used (cf. Documentation/powerpc/dawr-power9.rst in Linux sources). Consequently I had to take extra care not to have more then one watchpoint set at any given time or GDB would resort to using software watchpoints, painfully slow. I used to think watchpoints are for granted nowadays and before getting this system I didn't even think such a silly shortcoming would be possible in 2020 with a performance chip where the cost of a couple watchpoints is nothing in terms of silicon. I mean Intel x86 has had *four* of them as standard since 1985(!) in every single even most crippled implementation, and myself I have used this feature since 1991. And even embedded chips such as MIPS ones usually have at least two these days. Based on my quick research this shortcoming has now been corrected with POWER10, but I find the 35 years required to get on par with x86 a bit disappointing, and of course I won't be able to make use of it anyway. Second I need to find a new day job. Maciej
