Floating point optional

[samiam95124]

Make floating point arithmetic optional in the Pascal-P machine

The current state

Currently all floating point operations are allowed.

The desired result

In order to allow for smaller Pascal-P machine implementations/cores, the floating point ability could be removed. This is a fairly large section of code/core, and the ability is not used in all programs. Thus it could be made optional. As is the trend with such things, this could be implemented in such a way that the machine could be extended via loop defined software.

The proposal

By program option, floating point math operations are not directly executed, but instead send to csp operators. These csp operations are normally set to produce an error and halt. However, using the csp override method, these operations can be loop defined by the support library.

[electric-socket]

Nice idea, but probably breaks ISO 7185 compatibility.

[samiam95124]

Yes, absolutely. It would effectively be a flag that introduces a subset.

[samiam95124]

Ok, that was the short answer. If you know/knew me, there is a long answer as well.

Floating point hardware units are expensive. In terms of silicon area. In the old days this used to be painfully apparent, because (for example) the old 8086 chips used to have a separate floating point chip available for extra cost.

Nowadays chip vendors have a different problem, which is since about 2000, they are friggin' drowning in silicon. This is helped greatly by the fact that fabs, the guys who make the stuff, are separate companies that only care about pumping out mass quantities of ever smaller feature integrated circuits. Now there is way too much silicon in the world, but that is another story.

So FPUs (Floating point units) effectively disappeared. Or did they? On this side of the IC package (the outside), it would appear, but NOT on the inside. FPUs are still expensive in silicon area. For companies vending prepatterned silicon, ie., CPU and SOC (system on a chip) vendors, they are still drowning in silicon. However, for FPGA users and custom chip designers (like the company I work for!) that ain't so.

So there are actually two solutions to this:

1. Go back to using a floating point library (jess like the good ole' days).
2. Don't use floating point.

For the first method, use a library, this used to be a no-brainer. You got a floating point library and called it. But that was in the assembly language days. What about with HLLs? Well, actually, that is even easier. The low level code, that produced (in the case of Pascal-P6) you can do that same library call. In the case of pgen, it's calls at assembly time. In the case of pint, it's either external support calls to assembly, some really tricky HLL code, or a combination thereof. For example, given a basic set of four banger (+,-,*,/) routines in assembly, or even a one banger call (+), you can synthesize the rest with HLL code. The point here is that this is completely transparent to the user.

For the second method, you can rely on the fact that a large amount of programs don't use floating point math. And for the rest of them, you could easily refactor them to use integer math instead of using floating point. In the early days of microprocessors, when FPUs were rare and expensive, I used a Basic implementation that had no floating point. The way you handle fractions is by using fixed point math. You base all your calculations on (say) a two digit fraction, then you just do the math and rescale things based on multiply and divide. I could write a book on it, I did that for more than a year.

Now it turns out that Pascal is particularly well suited to isolate floating point operations. Professor Wirth was farsighted about such things. As in other languages, floating point sits at the top of the promotion pyramid, that is, any operation involving floating point yields a floating point result. That is, r := r+i where r is real and i is integer promotes integer to real for the addition. However, i := r+i is invalid because the result of r+i is real, and you can't just force that to be an integer again without telling the compiler about it, in terms of trunc() or round()[1]. Further, no integer operations yield floating point results with the one exception of / (divide). In fact, there is an integer only version of that in the div operation. C (for example) is far more cavalier about it's conversions.

Summing up

There are a lot of options for reducing the use of silicon space in Pascaline, and most users don't care about the subject at all, since basically all commercial CPUs have FPUs nowadays. That's why dropping the use of floating point is an option. In fact, it is really more of a "check", because you could just refrain from using floating point in your program. What the "no floating point" option really does is verify that you have not used floating point in your program, otherwise an error results.

[1] The specific point of that feature is that the compiler would never throw away parts if a number, in this case the fractional part, without a specific instruction from the programmer.