Hah, on a much smaller scale I had a phase early in my career where I had to wrangle an autoconf build system to work on many unix variants used in HPC. I got pretty fluent in the minimal, portable subset of Bourne shell that actually worked everywhere.
Also, some of the HPC platforms had terrible performance with autoconf and similar because they were terrible at fork/exec latency. Rather than doing copy-on-write virtual memory and fine grained time-slicing, like a typical workstation, they seemed to be doing stop-and-swap of whole processes or something. Something that took minutes on a typical workstation could take hours on the HPC service node.
Anyway, home sick with a fever, I got the weird impulse to figure ways to avoid forking subprocesses from the shell. A common one was invoking `expr` for arithmetic, so I started writing my own arithmetic library in pure Bourne shell.
It was decades ago, so I can't recite the actual code. But I remember that I tried a couple versions. My fever broke before I got around to multiplication and division, but I assumed I would just use naive iteration on top of addition/subtraction.
The first version was direct ASCII-encoded decimal operators that exploded the input strings into sequences of digits and iterated them using a case statement encoding the 10x10 sum and carry results. It used function call arg list to iterate the digits and reverse them, so it could then process sum digits from least to most significant.
Since I was processing operand strings from least to most significant digit, it was actually an arbitrary precision operator. I mapped the empty string operands as implicitly zero padded.
After that, I think I experimented with larger bases instead of decimal. E.g. split the string into groups of 2 or 3 decimal digits and encode 100x100 or 1000x1000 lookup tables. If I remember correctly, t wasn't very practical, as the larger case statements didn't really perform well.
Comments
Hah, on a much smaller scale I had a phase early in my career where I had to wrangle an autoconf build system to work on many unix variants used in HPC. I got pretty fluent in the minimal, portable subset of Bourne shell that actually worked everywhere.
Also, some of the HPC platforms had terrible performance with autoconf and similar because they were terrible at fork/exec latency. Rather than doing copy-on-write virtual memory and fine grained time-slicing, like a typical workstation, they seemed to be doing stop-and-swap of whole processes or something. Something that took minutes on a typical workstation could take hours on the HPC service node.
Anyway, home sick with a fever, I got the weird impulse to figure ways to avoid forking subprocesses from the shell. A common one was invoking `expr` for arithmetic, so I started writing my own arithmetic library in pure Bourne shell.
It was decades ago, so I can't recite the actual code. But I remember that I tried a couple versions. My fever broke before I got around to multiplication and division, but I assumed I would just use naive iteration on top of addition/subtraction.
The first version was direct ASCII-encoded decimal operators that exploded the input strings into sequences of digits and iterated them using a case statement encoding the 10x10 sum and carry results. It used function call arg list to iterate the digits and reverse them, so it could then process sum digits from least to most significant.
Since I was processing operand strings from least to most significant digit, it was actually an arbitrary precision operator. I mapped the empty string operands as implicitly zero padded.
After that, I think I experimented with larger bases instead of decimal. E.g. split the string into groups of 2 or 3 decimal digits and encode 100x100 or 1000x1000 lookup tables. If I remember correctly, t wasn't very practical, as the larger case statements didn't really perform well.