Best processors for trig?

The AN/UYK-44 CPU had built in trig instructions, including a single instruction rectangularpolar conversion feature. It use an odd floating point format where the exponents were base

16 instead of base 2. And for extra fast angular stuff, it supported a "BAM" type: binary angular measurement, where 0-360 degrees was mapped to 0-MAXUNSIGNED. That let you do a lot of angular calculations very quickly using integer ALU operations.

And it was definitely not BGA. :)

It was a whole rack of SEMs: approx 2x5" "DIMM" style modules (that were on ceramic substrates instead of fibergalss, IIRC).

All the computing power of an 8086/8087 combination, but neatly packaged in a cabinent the size of a small refridgerator with a

5-digit pricetag and requring hundreds of watts of power.

formatting link

Oh, and the software tools...

--
Grant Edwards                   grante             Yow!  Nice decor!
                                  at               
 Click to see the full signature
Reply to
Grant Edwards
Loading thread data ...

Unless you are especially interested in values _very_ close to 0 and

90 degrees (or perhaps 45 degrees for expressions like (tan(45)-1), why would you use floating point arithmetics ?

If you are really interested in such special cases, it usually indicates that doing some additional math would solve the problem without using trigonometric functions at all.

Anyway, by dividing the argument range into sufficiently small segments, the problem can be solved by 6th..8th degree polynomial, thus any DSP with Multiply-Add instructions are very handy.

Paul

Reply to
Paul Keinanen

In the 1970's I disassembled the PDP-11 FORTRAN run time library to check out how it was implemented. I did not find any functions that would have required more than the 4th degree for single precission and

8th degree for double precission.

Later analysis of VAX-11 FORTRAN revelee that even 3rd (6th degree for double) was used.

That range is far too wide. I would split the 1.0 to 2.0 range to 4-16 segments with appropriate coefficients.

Paul

Reply to
Paul Keinanen

5000 terms?

I recently needed an exp/log pair for a fixed-point DSP, and came up with the equivalent of the following code (recited from memory), which needs one loop iteration per mantissa bit. // as many as you need, enlarge tables accordingly #define BITS 10

// 2**-1 .. 2**-10 const double tab1[] = { 0.5, 0.25, 0.125, 0.0625, 0.03125, 0.015625, 0.0078125, 0.00390625, 0.001953125, 0.0009765625, };

// base ** tab1[i] const double tab2[] = { 1.4142135623731, 1.18920711500272, 1.09050773266526, 1.04427378242741, 1.02189714865412, 1.0108892860517, 1.0054299011128, 1.0027112750502, 1.00135471989211, 1.00067713069307, };

// compute 2**a, for a \in [0,1). double mypow(double a) { int i; double result = 1.0; for (i = 0; i < BITS; ++i) { if (a >= tab1[i]) { result *= tab2[i]; a -= tab1[i]; } } return result; }

// compute ld(a) for a \in [0.5, 1] double mylog(double a) { int i; double result = 0.0; for (i = 0; i < BITS; ++i) { // a inverse-of-tab2 table could be handy here if (a

Reply to
Stefan Reuther

Has anybody ever seen the execution times for the trig functions for say the 68K math coprocessor? Also, are any accuracy info given?

Reply to
Everett M. Greene

Yes, an SO-16 package would have been nice, wouldn't it.

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

... snip ...

I calculated ln2 as a Tschebychev polynomial in x1 = (x-sqrt(2))/(x

  • sqrt(2)) for a 2 Mhz 8080 in about 9 millisec, according to my notes (1982). About 5 sig. digits, 2nd order polynomial. The time included reducing the range to 1..2 and combining the characteristics. It also trapped zero or negative inputs. This was called for ln and log10 functions.
--
Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.
Reply to
CBFalconer

Which one? There was the 68881 which was followed by the 68882 which was slightly faster. I'm sure the manuals gave this info, but I'm not sure where mine are now. It's been 20 years since I needed that info.

Are they even made now? If you really need the info, let me know and I'll see if I can find my manuals (assuming they haven't been tossed).

~Dave~

Reply to
Dave

A $6 floating point flatpack SHARC can do near 1GFLOPS, you should easily be able to trig operations in less then a microsecond.

Reply to
stevepierson

Easy to interface to the bus of a slow 8 bit CPU like the 6502:

formatting link
About 32 byte memorymapped. But HCMOS is somewhat NMOS: 100mA and no easy way to get it in powerdown. Software for getting data in and out is worse: one has to emulate a protocol the 68k had in microcode, that slows it down. But there are 8 float-registers, so one can keep data during many calculations on chip. The bright side: they have microcoded a lot of trig-functions, integer-conversion, BCD-conversion.

No. In PGA68-package ( "RC" ) on ebay. There are 16, 20, 25, 32 MHz versions. Faster is usually better if only to make the interface to the bus easier.

To get even more obsolete/exotic: MIL-STD 1750A had float in microcode. And for the 1750B i think they extended the instructionset by some trig functions.

MfG JRD

Reply to
Rafael Deliano

Don't know about the 68K coprocessor, but at least the Pentium Processor Family Developer?s Manual Volume 3: Architecture and Programming Manual from 1995 gives clock counts for the x87 style stack based floating point instructions.

FADD 3/1 clocks FMUL 3/1 FDIV 39 FCOS 18-124 FPATAN 17-173 (Partial arc tan) FPTAN 17-173 (Partial tangent) FSIN 16-126 FSQRT 70 FYL2X 22-111 y * log2(x)

The operations are performed on the internal 80 bit stack word size.

Paul

Reply to
Paul Keinanen

Either is fine. I've just never seen the info anywhere and have looked for it.

If it's not too much bother, the info would be appreciated.

Reply to
Everett M. Greene

Its not a table with numbers, its chapter 8 "Instruction Execution Timing",

40 pages. A bit too much for a quick scan. That heap of data was probably done to obfuscate that they are not that fast. In their SANE softwarepackage that would use the FPU if available, but emulate it in software otherwise Apple would state that they are at similar precision faster in software then with the FPU. Depends on CPU and will not be true always. But Motorola gave up on it and didn´t do another one for the 68040 as far as i remember.

MfG JRD

Reply to
Rafael Deliano

I don't think that I'd calculate it that way. Even approach log((1+x)/(1-x)) is far better than that. I needed log(n) for integer n (up to 32-bit ints) about 15 years. A combination of table lookup and simple arithmetic improved speed 20 fold over FP methods.

Peter

Reply to
Peter Dickerson

You can also look at CORDIC functions. These can be implimented in an FPGA. Apparently the first HP calculators used this method to calculate all the normal trig functions to high precision using CORDIC functions.

Regards Anton Erasmus

Reply to
Anton Erasmus

The 68040 had some float operations in the processor itself. Not all of the functions supported by the 68882 though. AFAICR speedwise the

68040 were a bit faster than a similarly clocked 68030 + 68882 combination.

Regards Anton Erasmus

Reply to
Anton Erasmus

Yes, I learned about CORDIC from an old issue of the Hewlett-Packard Journal. Don't remember what was the sexy thing on the cover. An HP-35?

Roberto Waltman

[ Please reply to the group, return address is invalid ]
Reply to
Roberto Waltman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.