Timeline for Would a C compiler for the Apollo Guidance Computer be plausible?
Current License: CC BY-SA 4.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 11, 2024 at 21:07 | comment | added | supercat | @Joshua: No rule would forbid that, beyond the fact that it would undermine one of the major design purposes of C, i.e. to reduce the required complexity of a build system that could--with a programmer's assistance, generate reasonably efficient machine code. | |
| Feb 11, 2024 at 20:28 | comment | added | Joshua | As far as I know there ain't no rule that the compiler can't be a full tracing compiler and only emit recursive-enabled code for functions that actually are recursive. | |
| Sep 4, 2018 at 22:25 | comment | added | supercat | INDEX instruction before every instruction that accesses something on the stack. The penalty for re-entrant code wouldn't be as bad on the AGC as it would be on some other platforms, but would still be quite severe when using "raw" machine code (about a 2:1 cost in space and time) but perhaps not unworkable when using interpreted code. | |
| Sep 4, 2018 at 22:23 | comment | added | supercat | @PeterA.Schneider: On the AGC, the prologue for a non-reentrant non-leaf function would need to use two XCH instructions to move Q to a location which is hard-coded to hold that function's return address, and the epilogue would use two instructions (INDEX and TC) to jump there. A statement like x=y-z; would need three instructions--one to load -z, one to add y, and one to store the result. Allowing for re-entrancy would make require to adding three instructions to the prologue and epilogue to adjust a register used as the stack pointer, and would require adding an... | |
| Sep 4, 2018 at 16:25 | comment | added | supercat | @dan04: Although ANSI C undermined the usefulness of extended-precision floating-point types by botching the semantics of how they interact with variadic or non-prototyped functions (it should have kept the guarantee that all floating-point expressions get converted to a common type [possibly truncating to double precision] while providing a type that can be used to wrap/pass full-precision values to code that explicitly expects them) the semantics and performance they offered were much better than those achieved when performing computations directly on float and double. | |
| Sep 4, 2018 at 16:05 | comment | added | supercat | @dan04: An under-appreciated feature of IEEE-754's extended-precision type is that while it's often associated with the 8087, computations using that type were faster than computations on IEEE-754 double-precision type especially on 16-bit or 32-bit systems without an FPU. On such systems, it will generally be necessary to unpack the exponent and significand from a 64-bit value into five separate 16-bit words or three separate 32-bit words before doing anything with them, and then pack those words back into a 64 bit value afterword. | |
| Sep 4, 2018 at 15:57 | comment | added | supercat | @tofro: The Standard specifies that DBL_DIG must be at least 10, which would require a significant of at least 35 bits. If the Standard had only required conforming implementations to make it be at least 8, that would have greatly reduced (often by 50% or more) the cost of floating-point math on FPU-less systems that perform all math using the same floating-point type. On the ARM, for example, a type that combined a 32-bit significand word with explicit leading "1" and a 32-bit sign+exponent word could offer an excellent blend of precision and performance. | |
| Sep 4, 2018 at 14:54 | comment | added | supercat | @PeterA.Schneider: Unless a platform supports base+displacement addressing, storing variables on the stack is apt to be far less efficient than storing them at fixed addresses. Taking a 2:1 or worse performance and code-size hit to support recursion is typically not worthwhile. | |
| Sep 4, 2018 at 12:52 | comment | added | Peter - Reinstate Monica | I' no compiler writer but reentrancy seems simple (basically implement a stack). What's hard about it? | |
| Sep 4, 2018 at 9:33 | comment | added | PlasmaHH | @tofro: besides that annex F says that float has to match the iec 60559 single format, and even though only informative annex E requires FLT_MAX 1e+37 and FLT_EPSILON 1E-5 leading to pretty much 32 bit float. | |
| Sep 4, 2018 at 7:34 | comment | added | DevSolar | @dan04: Same for the Amiga / MC68851, and I guess lots of other platforms. | |
| Sep 4, 2018 at 4:33 | comment | added | dan04 | @slebetman: That was also the case for early PC C compilers (e.g., Microsoft QuickC and Borland Turbo C) before the x87 FPU became a standard feature. | |
| Sep 4, 2018 at 1:42 | comment | added | DrSheldon | @supercat: Note clarification to question. Hope this helps! | |
| Sep 3, 2018 at 23:15 | comment | added | slebetman | There's a few C compilers for microcontrollers that implement software floating point as a library and allow you to not link the floating point library if your program only use integers. | |
| Sep 3, 2018 at 20:10 | comment | added | tofro | The C standard actually doesn't set any limits to floating point precision. It just says double needs to be at least as precise as float. It's just a convention that most ompulers use IEEE754 for floating point, and that says "float is 32 bits" (both mantissa and exponent). | |
| Sep 3, 2018 at 19:49 | comment | added | alephzero | Wasn't there a recognized subset of C without floating point, back in the day? (A quick web search didn't find it - but I can't remember exactly what it was called). | |
| Sep 3, 2018 at 18:26 | history | answered | supercat | CC BY-SA 4.0 |