EML/Suite for the HP 35s

This port of EML/Suite started as a fork of the HP-32S family version with the intent of seeing whether its superior complex number handling would make a material difference.

(Spoiler: It does!)

Because there is no program file I/O with this device, the program is available in source code form only.

Usage

The subroutines are named the same as in the 32S family version, with the following extensions…

LBL	Fn	Stk	Description, Mnemonic
B	`x÷2`	1	Bisect (halve) 𝑥
C	`cos(x)`	4	Cosine of 𝑥 radians
D	`x÷y`	1	Divide 𝑥 into 𝑦
G	`log_x(y)`	2	base 𝑥 loG of 𝑦
H	`hyp(x,y)`	4	Hypotenuse, legs 𝑥,𝑦
J	`i`	4	imaginary number ⅉ
R	`sqrt(x)`	3	square Root of 𝑥
S	`y−x`	1	Subtract 𝑥 from 𝑦
T	`tau=2π`	4	Tau
V	`avg(x,y)`	4	aVerage of 𝑥 and 𝑦

I implemented 𝛕 as subroutine T instead of 𝜋 as P not merely because it was the right thing to do, but because I did not want to reassign the power function, breaking compatibility with the 32S version.

Resources

Operands are consumed and replaced with results in the same manner as the builtin equivalents. Prior elements on the stack may be overwritten by intermediate results, but no “litter” is left behind.

This version uses a few global registers:

• M during multiplication (LBL M) to avoid losing intermediate values due to the traditional 4-level stack
• X and Y in the hypotenuse calculation (LBL H) to work around the cost of squaring a number on the 4-level stack
• X and Y in cosine (LBL C) as well

Unlike the reference implementation, we don’t need more because the limitations below preclude implementing the more complicated functions, which tend to have greater resource requirements.

Limitations

Classic HP Stack

HP’s ancient (1972) 4-level stack design creates as much challenge for this 35s port as with the 42S one. You see this most acutely in the hypotenuse function (LBL H) which must perform two 4-slot calls (Q = square 𝑥) back to back, explaining its global resource use.

Single-Letter Labels

With but 26 global labels allowed and no option for locals, I was only able to port a subset of EML. I even had to cheat by inlining the `cosh(x)` implementation inside `cos(x)`, which calls it in the HP-42S and R47 versions.

K is the only one currently unused.¹

There are a few things I could do to recover a few more labels, but short of a widespread inlining campaign, I can’t implement the full ballpark accuracy suite. If you wish to see the harm this would do to the educational mission of this project, see LBL 8 in the HP-15C port. It wouldn’t get less vile in HP-32S form.

Tests

You might expect the test x=0? to be true for a complex number, but you’d be wrong! The check to handle the case of `ln(0)` being undefined on the 35s had to be done a different way, via the LBL F branch in LBL S above; the shared EML kernel that follows is also the target of GTO S006 from LBL A.

Imaginary Numbers

The definition of 𝑖 (our LBL J) had to include a negation to work around a branch-cut difference in the way the machine’s internal math works relative to how we’d prefer it did work. The designers weren’t wrong to choose this path, but it did require that we accommodate it.

Another oddity here is that the result gives a real part very near 0, causing the actual near-𝑖 result to scroll off the right side of the display. You have to use the arrow key to scroll it into view. The upside is that we get an answer at all; the calculator itself fails when you attempt to get the same result in the straightforward manner, 1 +/- √𝑥, causing the SQRT(NEG) error documented in the calculator’s manual. How the HP 35s can support complex numbers but be unable to handle this obvious path for generating them, I cannot say.

Complex Arithmetic

That quibble does not change the fact that the HP 35s has much better complex number handling than the 32S family from which it derives. Gone is the two-register hack storing the real and imaginary halves separately, and gone is the need for the special CMPLX ops. It is better even than the 42S in that you can enter a complex number directly on the stack or into a program using the 35s 𝑖 key, without needing to compose it on the stack first.

Yet, there are notable limitations in the 35s which affect EML/Suite. The biggie is that the 42S can take the logarithm of a negative real number and produce a complex result, whereas the 35s will complain LOG(NEG) when you do that.

Scattering a few explicit complex promotions² at key chokepoints solves that.

Like in the 42S port, this one forces rectangular mode at the top of the subtraction routine, LBL S. Alas, unlike on the 42S, not all complex arithmetic goes through this single chokepoint; the GTO S006 trick bypasses it, requiring that the 35s port also force rectangular mode at the top of LBL A to handle the Y=0 case.

License

These programs are © 2026 by Warren Young and offered under the terms of the MIT License.

---

1. ^{^} Even that was taken at one point, before I found good use of a nifty feature in the HP 35s that allows jumping into the middle of a subroutine. Without this trick, A and S would need to share a common Kernel, the prior owner of this label.
2. ^{^} The 35s idiom for that is adding 0+0𝑖, written in this program in the on-device shorthand “0i”. The 42S equivalent is pushing a 0 onto the stack and calling COMPLEX.