The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
Wasn't the source code for VMS released to the public a few years ago? Then I guess it would just to rewrite the HAL - VMS was ported to both the Alpha chip and Itanium, so they probably have defined some useful hardware abstractions ... and Wikipedia also claims that "a port to the x86-64 architecture is underway".
Wikipedia says that OpenVMS is closed source(!), but the section "Hobbyist programs" suggests that it is open for hobbyist and non-commercial use. So even if my memory is wrong about it being made "fully open" fairly recently, you could at least call it "ajar software"
We had a pair of VAX 785s (I think - my memory of the last millenium occasionally fails me) and were running real-time flight telemetry and analysis on them. So cool and, since we very close to the runway, very noisy! Jet fighters on reheat make a LOT of noise on take-off.
- I would love to change the world, but they won’t give me the source code.
Maybe there were good uVax implementations. But the first attempt to build a small Vax was the 730. From a performance point of view, it was a nightmare!
Friends of mine were using it and reported that had timed the filling an 80 char input buffer with spaces to take 20 milliseconds. A process switch took 100 ms - 1/10 second(!). In their project, they had to change the software architecture from three to two processes (and redistribute the functions) in order to reduce the required number of process switches; that significantly increased the performance of their application. It took just a few weeks before someone got hold of a big yellow-green "Turtle Wax" sticker to put on the front panel of the machine.
The 730 was an extremely microcoded machine, with a highly vertical architecture: While the 780 had a 96 bit microcode word, so that it could issue 96 signals per microcycle, the 730 had 24 bits, heavily multiplexed. So the meaning of one bit could depend a lot on other bits, and had to be decoded by a logic network before sent to the actual circuits. The hardware itself was also far simpler, so it took a lot more microcycles to perform one complete machine instruction.
Even the 780 had some hardware limitations, the strictest one (for the performance) was that all page tables had to be resident in memory; it couldn't handle a page fault in the page fault interrupt handler. In 1970 or 80, our university had one 780 with a whooping 1 megabyte of RAM. Whenever the electronics guys ran their circuit layout program, which used immense amounts of virtual memory, they had to reboot the machine with a large page table configuration so that more than 600K was taken by the page tables and resident part of the OS, slightly more than 300 kbyte was available for paging of user programs and non-resident OS parts. You may call it "CPU abuse" to run a VAX 780 CPU on 1 megabyte of RAM, but if you weren't there at the time, you would never believe the cost of RAM in those days...
I guess they figured if you were coming from a Unix/Linux background that's the way it's always been and you should know what to expect. But if you're coming from windows you need all the help you can get...you know the GUI thing and all!
I'm currently unsupervised, I know it freaks me out too! JaxCoder.com
Raymond Chen, in his delightful book "The old new thing" (based on his equally delightful blog of the same name, [^]) he tells about this web server that just had to be available 24/7, but some memory leak made it crash every now and then, every few days. To keep the service running while they debugged the software, they replaced the server with a small cluster and a load balancer: Whenever one of the machines were reaching memory saturation, it was taken out of the cluster and rebooted. In the meantime, the other machine served the users. Later, the other cluster node would be the one to be taken out and rebooted while the first served the customers.
They did find the memory leak, and the installation could go back to single server operation. (There was no need to run a cluster for performance reasons.)
Thumbs up for "The old new thing", both book and blog! The book is fun, but you can actually learn a whole lot from it, especially about legacy and backwards compatibility. (And especially if you just completed your degree and have very limited experience in the commercial world.)
Last Visit: 27-Jun-19 0:01 Last Update: 27-Jun-19 0:01