<div dir="ltr"><div>When I was tech editing "Operating Systems Concepts", tenth edition, around seven years ago, I downloaded the Linux source and searched all .c and .h files for float and double. There aren't any. Linux does not require floating point support, and that's likely true of other operating systems, where performance is key. It also means that Linux can run on RISC V without floating point support (I know the basic CPU doesn't include it).</div><div><br></div><div>As for microcode in Intel chips, translation of CISC instructions into its internally used RISC is done as lookups into a table that takes up a good portion of the chip die. </div><div><br></div><div>Rik</div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 8, 2024 at 2:40 PM Aron Insinga <<a href="mailto:aki@insinga.com">aki@insinga.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">See <a href="https://www.cs.tufts.edu/~nr/cs257/archive/ronald-brender/bliss.pdf" rel="noreferrer" target="_blank">https://www.cs.tufts.edu/~nr/cs257/archive/ronald-brender/bliss.pdf</a><br>
<br>
C allowed writing Unix with a limited amount of assembly code, but CMU's <br>
original BLISS-10 was designed to write an operating system with *no* <br>
outside assembly code.  Features like the 'MACHOP' (machine operation) <br>
builtin function made use of  the orthogonality of the PDP-10 <br>
instruction format to execute machine-specific instructions in-line.  <br>
(cf. the 'asm' extensions in some implementations of C.)  The PDP-10's <br>
36-bit word allowed single-precision floating point numbers to fit in <br>
machine words, so it had infix operators for both integer and <br>
single-precision floating point operations (which I presume were <br>
adequate for an operating system).<br>
<br>
When DEC chose an implementation language, they knew about C but it had <br>
not yet escaped from Bell Labs.  PL/I was considered, but there were <br>
questions of whether or not it would be suitable for a minicomputer.  On <br>
the other hand, by choosing BLISS, DEC could start with the BLISS-11 <br>
cross compiler running on the PDP-10, which is described in<br>
<a href="https://en.wikipedia.org/wiki/The_Design_of_an_Optimizing_CompilerBLISS-11" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/The_Design_of_an_Optimizing_Compiler<br>
BLISS-11</a> and DEC's Common BLISS had changes necessitated by different <br>
word lengths and architectures, including different routine linkages <br>
such as INTERRUPT, access to machine-specific operations such as INSQTI, <br>
and multiple-precision floating point operations using builtin functions <br>
which used the addresses of data instead of the values.<br>
<br>
In order to port VMS to new architectures, DEC/HP/VSI retargeted and <br>
ported the BLISS compilers to new architectures.<br>
<br>
What I find amazing is that they also turned the VAX MACRO assembly <br>
language (in which some of the VMS operating system was written) into a <br>
portable implementation language by 'compiling' the high-level CISC VAX <br>
instructions (and addressing modes) into sequences of RISC <br>
instructions.  I believe that this is similar to how modern CPU chips <br>
dynamically translate x86_64 instructions (or whatever) to an internal <br>
RISC format.<br>
<br>
- Aron<br>
<br>
(Disclaimer: I worked at DEC for a long time and VSI for a short time, <br>
but I wasn't responsible for the above work.)<br>
<br>
<br>
On 7/6/24 17:32, Charles H Sauer (he/him) wrote:<br>
> On 7/6/2024 3:56 PM, John R Levine wrote:<br>
>> On Sat, 6 Jul 2024, Clem Cole wrote:<br>
>>> Other systems programming languages followed, BCPL, BLISS, PL/360 <br>
>>> and even<br>
>>> B before C.<br>
>> The original version of BLISS was only for the PDP-10.  DEC <br>
>> retargeted it to the PDP-11 and VAX, but I think that was after Unix <br>
>> moved to the Interdata and possibly other machines.<br>
</blockquote></div></div>