+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: Not HP Calculators (/forum-7.html)
+--- Forum: Not quite HP Calculators - but related (/forum-8.html)
+--- Thread: Extending the precision of Woodstock or Saturn based calculators (/thread-8799.html)
Extending the precision of Woodstock or Saturn based calculators - Alejandro Paz(Germany) - 08-09-2017 07:17 AM
I was wondering if someone made any inroads in extending the precision of the algorithms implemented in the woodstock or (could also be nut) saturn based machines.
Let me explain:
Say the word is 32 nibbles long instead of 14 or 16. I now that it needs a new processor, so to say. And the P register and handling needs extension, and so on.
Note: I am aware of the extended precision done to the 41, I read something about it here in the forums. But it not is implemented with extra long working registers, nor has more than 13 digits.
What are your thoughts about it ?
See it as an experiment.
I am working on this parallel version of the woodstock core, and was wondering if one could achieve better precision by extension of the word and fixing of the algorithms.
I wanted to test with square root, I think it is quite simple and I have an over look of it, it doesn't need extra routines (at least the saturn version).
RE: Extending the precision of Woodstock or Saturn based calculators - Paul Dale - 08-09-2017 08:32 AM
I suspect it would be better to produce new algorithm for the higher precision. Nobody is going to make an advanced NUT processor when there are a plethora of adequate processors available already.
Pauli
RE: Extending the precision of Woodstock or Saturn based calculators - Massimo Gnerucci - 08-09-2017 10:00 AM
(08-09-2017 08:32 AM)Paul Dale Wrote: I suspect it would be better to produce new algorithm for the higher precision. Nobody is going to make an advanced NUT processor when there are a plethora of adequate processors available already.
Pauli
Uh, really?
RE: Extending the precision of Woodstock or Saturn based calculators - Paul Dale - 08-09-2017 11:04 AM
The Newt is a fantastic piece of work. It is replicating the NUT with minimal extensions. The registers are the same size, the maths routine likewise. Sure, it's got lots of registers and heaps of memory but the precision isn't increased.
It also isn't a commodity processing -- i.e. the price is high.
Pauli
RE: Extending the precision of Woodstock or Saturn based calculators - Massimo Gnerucci - 08-09-2017 01:22 PM
(08-09-2017 11:04 AM)Paul Dale Wrote: The Newt is a fantastic piece of work. It is replicating the NUT with minimal extensions. The registers are the same size, the maths routine likewise. Sure, it's got lots of registers and heaps of memory but the precision isn't increased.
It also isn't a commodity processing -- i.e. the price is high.
Pauli
It perfectly fits the scope it was developed for.
I was questioning your Nobody is going to make an advanced NUT processor ;)
RE: Extending the precision of Woodstock or Saturn based calculators - Alejandro Paz(Germany) - 08-10-2017 05:58 AM
Quote:I suspect it would be better to produce new algorithm for the higher precision. Nobody is going to make an advanced NUT processor when there are a plethora of adequate processors available already.
I am trying to develop such a processor, a better Saturn if you want. FPGAs are very flexible !
I have other algorithms for ARM/MIPS processors.
RE: Extending the precision of Woodstock or Saturn based calculators - Paul Dale - 08-10-2017 07:42 AM
(08-09-2017 01:22 PM)Massimo Gnerucci Wrote: It perfectly fits the scope it was developed for.
I was questioning your Nobody is going to make an advanced NUT processor
But faster is easy. More accurate is quite another matter entirely....
Pauli
RE: Extending the precision of Woodstock or Saturn based calculators - J-F Garnier - 08-10-2017 07:48 AM
(08-10-2017 05:58 AM)Alejandro Paz(Germany) Wrote:Quote:I suspect it would be better to produce new algorithm for the higher precision. Nobody is going to make an advanced NUT processor when there are a plethora of adequate processors available already.
I am trying to develop such a processor, a better Saturn if you want. FPGAs are very flexible !
I have other algorithms for ARM/MIPS processors.
Several years ago, I made similar investigations. Not really to get higher precision, but to provide higher speed and/or higher memory capacity.
For the HP41, I considered (in my Emu41) to implement a floating-point unit (using a unused Nut opcode), with the goal to simply re-write the system math routines. I ever made it (and will no more try) but some traces of my thoughts can still be found in my Emu41 sources (nutcpu.c).
For the HP71, I once considered to increase the width or the A address field from 5 to 6 nibbles, to increase the memory space. But the compatibility problems with the existing firmware were too important, and I gave up.
I also considered a FPU extension.
All I did in my Saturn emulation was (as you know) to add the R5-R7 registers (allowed by the opcode map) and increase the stack depth, although the HP71 firmware was not changed to take benefit of it.
Fell free to re-use these ideas!
J-F
RE: Extending the precision of Woodstock or Saturn based calculators - Alejandro Paz(Germany) - 08-10-2017 12:22 PM
Quote:For the HP71, I once considered to increase the width or the A address field from 5 to 6 nibbles, to increase the memory space. But the compatibility problems with the existing firmware were too important, and I gave up.
I also considered a FPU extension.
All I did in my Saturn emulation was (as you know) to add the R5-R7 registers (allowed by the opcode map) and increase the stack depth, although the HP71 firmware was not changed to take benefit of it.
I remember you talked about the extra R registers, I also wondered about the free slots, so to say, in the opcode map.
The increased stack would remove the need for that software stack implementation, it allows for extra 16 levels if I'm not mistaken. I just wonder how many times other software uses it (besides the ROM).
I don't want to add too many unnecessary opcodes but I think there are a couple of tricks being used that could benefit for an extra opcode here and there, like checking if the sign digit is a 9.
RE: Extending the precision of Woodstock or Saturn based calculators - Paul Dale - 08-11-2017 03:07 AM
A single opcode to do the RPL end sequence might be worthwhile. It would save two decode and execute cycles very often.
Pauli
RE: Extending the precision of Woodstock or Saturn based calculators - Alejandro Paz(Germany) - 08-11-2017 06:04 AM
And I'd really like a higher resolution 48
, not kidding. I have this nice 160x104 LCD sitting on my desk. Together with some 160x160, and that nice Sharp memory display at 400x240 (like what the DM42 has). That is always the problem how to upgrade something without breaking everything that works.
On the speed:
I talk about the 1LF2 (HP-71):
One of the issues with the Saturn implementation is that with 4 bit memory width, you need as many cycles as nibbles to fetch the opcode. And then one extra cycle per calculated nibble.
With say 16 bit wide memory one could fetch many opcodes in one cycle, most in two. Extending the width of the internal alu to say 16 bits, that of course poses other "hurdles" on implementation but it is doable, one could execute word opcodes in 4 cycles, plus fetch.
A 64 bit parallel ALU could perform word opcodes in 1 cycle, needs 881 LUTs in a MachXO2, 4 A..D registers. Not bad.
There are a couple possibilities for incrementing the speed, rising the clock is one of them, but not the best without addressing memory bandwidth. The HP48 uses byte accesses, read-before-write for RAM. Lots of work, if one wants
RE: Extending the precision of Woodstock or Saturn based calculators - Claudio L. - 08-11-2017 04:09 PM
(08-11-2017 03:07 AM)Paul Dale Wrote: A single opcode to do the RPL end sequence might be worthwhile. It would save two decode and execute cycles very often.
Pauli
That opcode was already done on the 49G+/50G internal Saturn emulator.
Other new opcodes worth adding are MOVEDN and MOVEUP for the memory copying routines, those are responsible for most of the speedup of the 50g vs 49g.
RE: Extending the precision of Woodstock or Saturn based calculators - Alejandro Paz(Germany) - 09-14-2017 11:38 AM
I have been busy doing the "extending the precision" of the algorithms, I coded a simulator for an extended version of the Saturn. I did change the encoding, P has now 5 bits instead of 4. And there are some extra registers.
Calculating the square root of 5 needs as you can guess double the amount of executed opcodes as in the original Saturn.
All the code to the experiment, called Parallel Neptune Core, can be found here.
The source file of the sqrt function with the equivalent Saturn code follows:
Code:
1 ;
2 ; Number format extended form
3 ;
4 ;
5 ; | <------ A ------> |
6 ; | <-- X --> |
7 ; | XS|
8 ; WS-1 4 3 2 1 0
9 ; +---+--- ... ---+---+---+---+---+---+
10 ; A/C | S | | S | E | E | E | E |
11 ; +---+--- ... ---+---+---+---+---+---+
12 ;
13 ; +---+--- ... ---+---+---+---+---+---+
14 ; B/D | 0 | WS - 2 digits significand |
15 ; +---+--- ... ---+---+---+---+---+---+
16 ;
17 ; 9 as Significand sign means negative number
18 ; Digits 5..9 as exponent sign means negative exponent
19
20 000000 2000001E loadp #30 ; P= 14
21 000001 31300005 ldn b,#5 ; LC(1) #5
22
23
24 ;
25 ; SQRT
26 ;
27 ; A exponent in A field
28 ; B significand in m field
29 ;
30 ;
31 ;
32 ;
33 ;
34 ;
35 ;
36
37 SQRT_Full: ;
38 ; =SQR15
39 ; XM=0
40 ; SB=0
41 ; SETHEX
42 ; A=A+1 XS
43 ; A=A-1 XS
44 ; SETDEC
45 ; GONC =SQR17
46 ; ?A#0 B
47 ; RTNYES
48 ; ?A#0 S
49 ; GOYES L_0C563
50 ; RTN
51 ; *********************
52 ; =SQR17
53 ; B=0 S
54 000002 19431F00 mov.w c,b ; C=B W
55 ; ?B=0 W
56 ; GOYES =SQR70
57 ; ?A=0 S
58 ; GOYES L_0C56D
59 ; L_0C563
60 ; P= 0
61 ; LC(2) #A
62 ; GOTO =INVNaN
63 ; L_0C56D
64 000003 08331F00 add.d.w b,b ; B=B+B W
65 000004 08331F00 add.d.w b,b ; B=B+B W
66 000005 08341F00 add.d.w b,c ; B=B+C W
67 000006 19420400 mov.a c,a ; C=A A
68 000007 08440400 add.d.a c,c ; C=C+C A
69 000008 19401F00 mov.w c,0 ; C=0 M
70 000009 5300000B jnc SQRT_1 ; GONC L_0C583
71 00000A 0E491F03 not.d.m c ; C=-C-1 M
72 SQRT_1: ; L_0C583
73 00000B 19420400 mov.a c,a ; C=A A
74 00000C 19241F03 mov.m a,c ; A=C W
75 00000D 08441F00 add.d.w c,c ; C=C+C W
76 00000E 08441F00 add.d.w c,c ; C=C+C W
77 00000F 08241F00 add.d.w a,c ; A=A+C W
78 000010 20000000 loadp #0 ; P= 0
79 000011 1120FFFF neq.p a,0 ; ?A#0 P
80 000012 54000014 jt SQRT_2 ; GOYES L_0C59B
81 000013 1C301F00 sr.d.w b ; BSR W
82 SQRT_2: ; L_0C59B
83 000014 1C201F00 sr.d.w a ; ASR W
84 000015 19401F00 mov.w c,0 ; C=0 W
85 000016 2000001E loadp #30 ; P= 14
86 000017 31400005 ldn c,#5 ; LC(1) #5
87 000018 1A341F00 ex.w b,c ; BCEX W
88 SQRT_3: ; L_0C5A9
89 000019 1C30FF00 sr.d.wp b ; BSR WP
90 00001A 0D31FFFF sub.d.p b,#1 ; B=B-1 P
91 SQRT_4: ; L_0C5AF
92 00001B 0931FFFF add.d.p b,#1 ; B=B+1 P
93 00001C 0C431F00 sub.d.w c,b ; C=C-B W
94 00001D 5300001B jnc SQRT_4 ; GONC L_0C5AF
95 00001E 08431F00 add.d.w c,b ; C=C+B W
96 00001F 1D401F00 sl.d.w c ; CSL W
97 000020 24000000 decp ; P=P-1
98 000021 53000019 jnc SQRT_3 ; GONC L_0C5A9
99 ; *********************
100 SQRT_5: ; =SQR70
101 ; SB=0
102 SQRT_6: ; L_0C5C6
103 000022 10401F00 eq.w c,0 ; ?C=0 W
104 000023 54000026 jt SQRT_7 ; GOYES L_0C5D1
105 000024 0D410200 sub.d.x c,#1 ; C=C-1 X
106 000025 1C400200 sr.d.x c ; CSR X
107 SQRT_7: ; L_0C5D1
108 000026 41000000 stop ; RTNCCRE: Extending the precision of Woodstock or Saturn based calculators - Alejandro Paz(Germany) - 09-14-2017 11:47 AM
In the repository here there is a Parallel Saturn core, written in verilog. It is still a work in progress. I just coded, after much thought, a pre-fetching BUS controller.
The Parallel Saturn should improve the throughput in three different ways:
Increasing memory bandwidth for fetch: I opted for a 16 bit memory width, some opcodes are 2 nibbles long, 2 optimally positioned opcodes could be fetched at once. This condition is extra checked.
Increasing memory bandwidth for data access: again 16 bit accesses should improve transfers. Alignment issues arise here and read-before-write cycles are needed.
Increasing the width of the ALU path: Using 64 bit registers at once, while limits the maximum frequency on the target FPGA (<10 MHz), should provide abundant improvement on long executing opcodes.
The ALU is mostly coded, the bus controller is partially coded, no data accesses yet. The rest is a rehash of my nibble-serial (but fully working) 1LF2 implementation.
Let's see if I can fully realize this other project
. Even at 2 MHz, it should be many times faster than a Yorke, let's see.
RE: Extending the precision of Woodstock or Saturn based calculators - sa-penguin - 09-23-2017 07:48 AM
Oddly enough, I was looking at extended precision math just the other week - on a Z80.
Extended precision data was held in data registers, and the number of registers to use was the main variable (if set to zero, only the Stack registers are used).
I appreciate you guys are talking about CPU level instructions. I'm sill thinking about the higher levels (like how to display the result). Extending the precision by a single register should give proof of concept, check the new math routines, yet not slow down processing too much.
Start with divide by 3, and square root of 5, before jumping to : asin(acos(atan(sin(cos(tan(1/9))))))
RE: Extending the precision of Woodstock or Saturn based calculators - Alejandro Paz(Germany) - 09-24-2017 07:57 AM
Quote:Start with divide by 3, and square root of 5, before jumping to : asin(acos(atan(sin(cos(tan(1/9))))))
That's why I used 5 as an example for the square root
.Anecdotally, some TI calculators like the TI-82, TI-83, TI-84, TI-85 and TI-86 among others use a Z80 as main processor. They can be divided in two groups lower and upper end. Both groups use very similar routines, the difference lays in the precision of the algorithms used, really minimal, like 2-4 digits and larger exponents.
But, the interesting part is that the numbers are stored in memory and used in place. The Z80 has a full complement of BCD friendly opcodes add, sub, daa (for addition and subtraction), and 4 bit shifts between accumulator and memory !, and many 16 bit pointers. All these resources are very well exploited in the mentioned models.
The whole math group of routines in the Saturn takes like 4 kbytes of memory, in the case of the Z80 (like in the TI-8x but not the 89) it takes, if I'm not mistaken, like 10 kbytes with the inflexibility of having the numbers always fixed in memory.
One could tailor such routines to use BC, DE, and HL but that means only 6 digits. I think that the way the TIs handle the whole is quite clever. That is a point where the Z80 actually excels in comparison with other more modern processors. Always talking about packed BCD. Nowadays one can achieve quite a bit more performance using base 100 (like I did), base 10000 (like the unix command bc) or greater bases like newRPL and others. Something doable when you have a relatively fast division and multiplication instructions, something totally lacking in the Z80. (The Z180 has a mul instruction) and memory constraints are not as severe as they once were !.
Another anecdote: Some like 20 years ago, I decided to use the H8/300H (A then Hitachi processor much like but not compatible with the MC68k) as the basis for my handheld calculator. This processor has 8 32 bit registers, as you can imagine I used the registers to temporarily contain the fractions of the floating point registers as I performed calculations, limited to 16 packed BCD digits. My target speed was like 8 MHz and that made kind of sense. Today, I'd go with a greater base, it just makes more sense with a RISC processor.
I also developed an AVR based BCD four function package with 16 digits precision. The AVR doesn't help at all with BCD
and unrolled routines needed quite a bit of space.
RE: Extending the precision of Woodstock or Saturn based calculators - Alejandro Paz(Germany) - 09-28-2017 12:40 PM
I have updated the Parallel Saturn core. At this point many instructions have been implemented. Some instructions are still missing like the ones dealing with device configuration, shutdown, interrupts. Memory read is partially implemented and memory write is still missing. But there is enough to let the synthesizer give us an idea of how big and fast it is. Big and slow for a MachXO2-7000ZE1
Code:
Design Summary
Number of registers: 1720 out of 7209 (24%)
PFU registers: 1718 out of 6864 (25%)
PIO registers: 2 out of 345 (1%)
Number of SLICEs: 3076 out of 3432 (90%)
SLICEs as Logic/ROM: 3073 out of 3432 (90%)
SLICEs as RAM: 3 out of 2574 (0%)
SLICEs as Carry: 309 out of 3432 (9%)
Number of LUT4s: 6151 out of 6864 (90%)
Number used as logic LUTs: 5527
Number used as distributed RAM: 6
Number used as ripple logic: 618
Number used as shift registers: 0
Number of PIO sites used: 46 + 4(JTAG) out of 115 (43%)
Number of block RAMs: 16 out of 26 (62%)
Report: 3.212MHz is the maximum frequency for this preference.90 % of this FLGA is pretty big, and the maximum speed is well, slow.
There are a couple of important points to consider:
The 64-bit computations, ADD, SUB, Logic and a mux are performed between two consecutive flanks of the clock. I haven't attempted any optimization here beyond latching both source arguments (Line 241..248, saturn_alru.v). The slowest path goes through the subtract unit, as expected.
But clock speed doesn't tell the whole story, if we do not know how many clocks are needed for an opcode. Small opcodes like P=n take 4 clocks to complete but fetch can take up to 3 clocks. While the per-fetcher does a pretty good work it can be greatly improved. Jumps take 2 clocks plus fetch. An unaligned opcode needs at least 2 extra clocks for fetch.
For comparison, the nibble serial implementation on the same FPGA can achieve 16 MHz. But opcodes need many more cycles:
Code:
Opcode | Serial | Parallel
-------|--------|---------
B=B+C W| 27 | 3+4
GONC | 9 | 3+227 cycles @ 16 Mhz = 1.68 us
7 cycles @ 3.2 Mhz = 2.18 us
9 cycles @ 16 Mhz = 0.5625 us
5 cycles @ 3.2 Mhz = 2.18 us
[/code]
I think that without improving the pre-fetcher it will be difficult to see any gain
. Fetch and subsequent execute and streamlining of the fetch state machine. At least one clock can be dropped as ST_INIT is not really needed, imho.
The ALU path can also be extended to two cycles allowing to double the frequency.