Obsolete C for you and me [LWN.net]

Obsolete C for you and me

Posted Dec 9, 2023 15:24 UTC (Sat) by Wol (subscriber, #4433) [Link] (2 responses)

> I'm not sure where C was being written in the 1970s and 1980s that didn't have an FP unit.

Intel before the (was it) 486? Or more likely the 386. Which iirc we're talking early 90s. I'm sure I was using a load of 286 computers when I started that new job in 1989 ...

Cheers,
Wol

Obsolete C for you and me

Posted Dec 11, 2023 10:23 UTC (Mon) by taladar (subscriber, #68407) [Link] (1 responses)

IIRC 386 and 486 had SX and DX variants and the former had no FPU and the latter did.

Obsolete C for you and me

Posted Dec 11, 2023 11:02 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

That's true for the 486, but no 386 had a built-in FPU - the 386SX had a 16-bit data bus and the 386DX had a 32-bit one.

Obsolete C for you and me

Posted Dec 9, 2023 15:31 UTC (Sat) by Paf (subscriber, #91811) [Link] (7 responses)

Well, there were examples, for sure - the Apple II didn’t have hardware FP, for instance. But it’s certainly not the case that hardware FP support wasn’t common (at least on big stuff).

Obsolete C for you and me

Posted Dec 9, 2023 15:35 UTC (Sat) by willy (subscriber, #9762) [Link] (6 responses)

Were people really writing significant amounts of C on bittyboxes like the Apple II? My background in that era was a lot of BASIC, some Pascal, some assembler. Fortran and C were for the Real Computers in the data centre.

Obsolete C for you and me

Posted Dec 9, 2023 15:50 UTC (Sat) by Wol (subscriber, #4433) [Link]

I dunno about significant, and I couldn't put a date on it, but early 90s I took over maintaining C programs running on PCs. That was Microsoft C 5. And we made extensive of use of overlays to get round the 640K/1M memory limit. So I guess there would have been quite a lot of PC C round about that time.

(That was the program(s) I set -W3 / -W4 on.)

Cheers,
Wol

Obsolete C for you and me

Posted Dec 10, 2023 1:30 UTC (Sun) by Paf (subscriber, #91811) [Link] (1 responses)

I don’t *think* so, but I wasn’t around for that - I’m in my 30s, I was just pretty sure several early personal computers lacked hardware FP because I vaguely remember when it started appearing in the 90s(?).

The point is just that with and without hardware FP both existed, I guess.

Obsolete C for you and me

Posted Dec 10, 2023 11:11 UTC (Sun) by Wol (subscriber, #4433) [Link]

Just to throw it into the mix, the minis I worked on had microcoded Fixed Point BCD. And it was fast, even if as the programmer you had to be careful to take care of the decimal point ...

Cheers,
Wol

Obsolete C for you and me

Posted Dec 10, 2023 3:11 UTC (Sun) by mjg59 (subscriber, #23239) [Link] (2 responses)

Not so much, but it was certainly the case for Amigas and STs and only very high end versions of those had FPUs

Obsolete C for you and me

Posted Dec 10, 2023 3:19 UTC (Sun) by jake (editor, #205) [Link] (1 responses)

> but it was certainly the case for Amigas and STs and only very high end versions of those had FPUs

hmm, i wrote the code for my 3D graphics grad school class in C on an Amiga 1000 in 1986 or 7 ... i suppose it is possible that it was all software floating-point, but i certainly did not encounter any problems in that regard ...

jake

Obsolete C for you and me

Posted Dec 10, 2023 3:26 UTC (Sun) by mjg59 (subscriber, #23239) [Link]

The A1000 was a 68000, which definitely had no hardware FPU. The first Amiga that shipped with an FPU by default was the A3000. Compilers would happily let you use floats and just fall back to software emulation for that.

Obsolete C for you and me

Posted Dec 9, 2023 15:51 UTC (Sat) by pizza (subscriber, #46) [Link] (11 responses)

> Hardware floating point has been around since the IBM 704 in 1954. It was also available on many PDP-11 models. The Sun-3 had an FP unit. I'm not sure where C was being written in the 1970s and 1980s that didn't have an FP unit.

"Has been around" and "available on many models" is a _long_ way from "can assume it's generally/routinely available" especially in the 1970s and 1980s.

Indeed, it wasn't until the early 1990s that personal computers of any sort could be expected to have a built-in FPU (eg i486 in 1989, 68040 in 1990). ARM didn't have an _architectural_ FP spec until the v7 family (ie Cortex-A) which didn't launch until the early 2000s.

Even in the UNIX realm, SPARCv7 didn't have an architecturally defined FPU, and many different ones were bolted onto the side. SPARCv8 (~1990) formally added an architectural FPU [1], but it was still technically optional and many implementations (SPARCv8a) lacked all or part of the FPU instructions) DEC Alpha launched in 1992 with a built-in FPU, but its predecessor (ie VAX, PDP) didn't necessarily come with FP hardware either, as you yourself mentioned. MIPS defined an FP spec, but it was an external/optional component until the R4000/MIPS-III in 1991. Unsually, PA-RISC appears to have an FPU for all of its implementations, which started arriving in 1988.

So, no, you couldn't generally rely on having an FP unit until the early 1990s. even then you had to be using fairly new equipment. Prior to that, FPUs were an (expensive!) option that you only opted for if you needed one. Everyone else had to make do with (very slow) software-based FP emulation, or rewrite their algorithms to use fixed-point mathematics, The latter approach is _still_ used wherever possible when performance is critical.

Heck, even today, the overwhelming majority of the CPU cores shipped still lack any sort of FPU, and I'd bet good money most of those are running predominately C or C++ codebases. (Yes, I'm referring to microcontrollers...)

[1] Incidentally, SPARCv8 was the basis for the IEEE754 floating point specification.

Obsolete C for you and me

Posted Dec 9, 2023 16:27 UTC (Sat) by pizza (subscriber, #46) [Link] (1 responses)

> ARM didn't have an _architectural_ FP spec until the v7 family (ie Cortex-A) which didn't launch until the early 2000s.

Correction -- Like so many other ARM things, they have a wide variety of floating point units that operated using different instructions; it wasn't until armv7 that you could expect/rely on a consistent FP baseline that worked the same way.

(The first ARM processor with the option of FP support was the ARM6 (armv3) in 1991)

Obsolete C for you and me

Posted Dec 9, 2023 16:44 UTC (Sat) by willy (subscriber, #9762) [Link]

AFAIK the only change to ARM FP insns has been the introduction of VFP (analogous to the MMX/SSE/... transition on x86). The Weitek coprocessor had its own insn set, but the FP emulator translated ARM FP insns into Weitek insns. The FPA10, FPA11 and FPEmulator all had the same insn set.

Obsolete C for you and me

Posted Dec 9, 2023 16:37 UTC (Sat) by willy (subscriber, #9762) [Link] (8 responses)

SPARCv8 was not the basis for IEEE 754. That standard was issued in 1985, and the first v8 chips were released in 1992. Wikipedia has:

"This standard was significantly based on a proposal from Intel, which was designing the i8087 numerical coprocessor; Motorola, which was designing the 68000 around the same time, gave significant input as well."

And yes, I'm aware that personal computers didn't have much hardware FP available, but my contention is that there wasn't much C being written on PCs of that era.

Also, I don't think an "architectural spec" is particularly meaningful. I was active in the ARM scene and I remember the Weitek coprocessor, the FPA10, FPA11 and the infamous mixed endian FP format. People used floating point with or without hardware, and with or without an architectural spec.

Obsolete C for you and me

Posted Dec 9, 2023 17:15 UTC (Sat) by Wol (subscriber, #4433) [Link] (1 responses)

> And yes, I'm aware that personal computers didn't have much hardware FP available, but my contention is that there wasn't much C being written on PCs of that era.

Well, I can think of at least one major program from that era ... the linux kernel ... (which was originally written for one of the early 386's, no?)

Cheers,
Wol

Obsolete C for you and me

Posted Dec 9, 2023 21:34 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

While true, Linux avoids FP (and SIMD) in its own code.

Obsolete C for you and me

Posted Dec 9, 2023 19:08 UTC (Sat) by pizza (subscriber, #46) [Link] (5 responses)

> And yes, I'm aware that personal computers didn't have much hardware FP available, but my contention is that there wasn't much C being written on PCs of that era.

During the 70s and early 80s, sure, not a lot of C on "personal" (ie non-UNIX) computers. but by the late 80s, that had changed.

Lattice C was released for DOS in 1982. Microsoft repackaged it for Microsoft C 1.0 in 1983. Borland released Turbo C in 1987, Watcom C was released in 1988 (and was the overwhelming favorite for game developers) GCC's first releases also landed in 1987.

While the 8087 FPU has been part of the x86 family since its introduction the late 70s, it was an expensive option, and as a result very little software was written that could directly take advantage of it. That had nothing do with the choice of programming language.

Obsolete C for you and me

Posted Dec 9, 2023 20:38 UTC (Sat) by willy (subscriber, #9762) [Link] (4 responses)

Thanks. I think our different experiences may be leading to our differing opinions. I was using floating point arithmetic in BBC BASIC on a 6502 in the 80s. Sure, it wasn't as fast as using integer arithmetic, but it was fast enough for my purposes.

https://beebwiki.mdfs.net/Floating_Point_number_format

If you're from a games background then the program is never fast enough ;-)

As an aside, I think the fact that Unix doesn't use floating point is quite crippling. If the sleep() syscall took a floating point argument, it would have meant we didn't need to add msleep(), usleep() (and I guess soon nsleep()). The various timespec formats would still need to exist (because you can't lose precision just because a file was created more than 2^24 seconds after the epoch), but _relative_ time can usually be expressed as a float. Indeed, Linux will round the sleep() argument -- see https://lwn.net/Articles/369549/

Floating-point in syscalls (was Obsolete C for you and me)

Posted Dec 9, 2023 21:52 UTC (Sat) by dskoll (subscriber, #1630) [Link] (2 responses)

nanosleep has existed for quite some time, so no need for an nsleep.

I don't really see a need for supporting floating point in UNIX system calls like sleep. Seems like overkill to me.

difftime returns the difference between two time_t objects as a double. But seeing as time_t in UNIX has only one-second resolution, that seems a bit silly to me, unless it's to prevent overflow if you subtract a very large negative time from a very large positive time.

Floating-point in syscalls (was Obsolete C for you and me)

Posted Dec 9, 2023 21:58 UTC (Sat) by willy (subscriber, #9762) [Link] (1 responses)

Double makes more sense as the result of subtracting two timespecs. See

https://www.infradead.org/~willy/linux/scan.c

and think how much more painful it would be to use some fixed point format (like, I don't know, a timespec)

I'm sure I could use a single precision float for this purpose, but that would definitely stray into the realm of premature optimization.

Floating-point in syscalls (was Obsolete C for you and me)

Posted Dec 9, 2023 23:09 UTC (Sat) by dskoll (subscriber, #1630) [Link]

Sure, yes, timespec has nanosecond precision. difftime takes arguments with only one-second precision.

Obsolete C for you and me

Posted Dec 10, 2023 19:40 UTC (Sun) by smoogen (subscriber, #97) [Link]

wouldn't a floating point 'sleep' then depend on how the architecture interpreted whatever 'floating point' down to 'steps' so you would end up with different 'small time' values on different computers. (especially if the sleep was calculated from an equation before being set.) If you are already looking at 'millisecond' sleep times you probably want to always 'sleep' for teh same amount and not to depend on floating point math which might change from CPU or firmware revision.