SoylentNews is people
SoylentNews
Arthur T Knackerbracket has found the following story:
Ken Bowles, a UC San Diego software engineer who helped popularize personal computers in the 1970s and '80s through advances that were exploited by such entrepreneurs as Apple's Steve Jobs, died on Aug. 15 in Solana Beach. He was 89.
His passing was announced by the university, which said that Bowles, an emeritus professor of computer science, had died peacefully.
Bowles was not well-known to the general public. But he was famous in computer science for helping researchers make the leap from huge, expensive mainframe computers to small "microcomputers," the forerunner of PCs.
He was driven by the desire to make it faster and easier for researchers and programmers to work on their own, and to develop software that could be used on many types of computers.
By 1968, Bowles found himself in the perfect spot to push his vision. He was appointed director of the university's computer center, just three years after joining the faculty.
University historians say Bowles taught his students to write and rewrite code on the world's first microprocessors, the chips that revolutionized the computer industry in the 1970s. They were soon writing programs expressly for microcomputers, bypassing mainframes.
Bowles and his team also adopted and modified Pascal, an early programming language that was opening up computer science. The modified version became known as UCSD Pascal and was widely used to teach people how to program.
[...] "The development of UCSD Pascal was a transformative event not just for UCSD but for all of computer science," according to a statement by Dean Tullsen, chair of the department of computer science and engineering at UC San Diego.
"It was arguably the first high-level programming system that both worked on small systems that schools, most businesses, and eventually individuals could afford, and was portable across many systems."
-- submitted from IRC
(Score: 2) by ledow on Wednesday October 10 2018, @02:37PM
The problem of such systems is fairly obvious though:
You're paying the code conversion costs all the time it's executing.
If you port the source code, and then compile once, the initial compile is "slow" but everything else operates at native speed for the rest of its existence.
Compile-times are rarely cared about by anyone but developers. Run-times are cared about by everyone.
The only way that I can see to combat that - and some bright spark will tell me that Some System X already does it - is to put the source into the executable itself (as just one dormant ELF section, for instance) and have the system "recompile" if it doesn't find a binary ELF section relevant to the architecture it's currently running on (or it detects corruption or changes, etc.). Then, when compiled, it can add that architecture's compiler output into the executable as a new ELF section should it ever happen to run on that system again.
With a bit of "you can always prune all ELF sections and it'll just regenerate the necessary code if things get too large" built into a "strip"-like tool, and a standard for bundling the source in a portable fashion, you could easily enjoy the advantages of (and even have an ELF section for) p-Code like that, while also providing compatibility across all systems, no run-time hit (except on the first run) and a "native" compiled bundle for any platform that generates itself whenever you run it on a new platform. The only cost is executable size, but most of that would NOT be ELF sections relevant to you anyway, so you wouldn't need them in memory.
I think Apple tried this a bit with their Universal Binary, but there was no automatic process and (obviously) no source code in those instances.
But there's nothing stopping you using "p-code" as the base source code, and then compiling optimised native versions from it which are the things that actually execute, and bundling them back into the executable.