[HN Gopher] A benchmark of three different floating point packag...
___________________________________________________________________
A benchmark of three different floating point packages for the 6809
Author : ingve
Score : 35 points
Date : 2024-10-14 09:25 UTC (4 days ago)
(HTM) web link (boston.conman.org)
(TXT) w3m dump (boston.conman.org)
| mannyv wrote:
| If you can find a copy Apple's SANE for the 6502 test it. It was
| faster than hardware fpus. That was according to a friend who was
| an FP geek back when.
| spc476 wrote:
| First off, the assembler is for a Motorola 6809, which is _not_
| a 6502. Second, one benchmark result I found [1] showed it
| being a bit slower than some alternatives.
|
| [1] https://www.callapple.org/programming/sane-programming-on-
| th...
| adrian_b wrote:
| Motorola MC6809 was much faster for floating-point
| computations than any other 8-bit microprocessor, because it
| not only had 16-bit additions and shifts, but it also had 8
| bit by 8 bit multiplications. No other 8-bit microprocessor
| had multiplication instructions.
|
| MC6809 had a very beautiful ISA in comparison with all other
| 8-bit microprocessors, but it was launched too late, in 1979,
| when there already were the 16-bit microprocessors Intel 8086
| and Motorola MC68000.
|
| Motorola had made the mistake of developing simultaneously
| two incompatible instruction sets, MC6809 intended for cheap
| CPUs and MC68000 intended for expensive CPUs. They should
| have developed a single architecture, with a stripped-down
| version of MC68000 for cheap CPUs, like they have done later
| with MC68008, but only when it was too late, because the
| cheap version of Intel 8086, i.e. Intel 8088, had already won
| the IBM PC.
| anthk wrote:
| The 6809 works great under the Vectrex. It's dumb easy to
| generate a game with vectors there, even more than a raster
| game with a 6502.
| dboreham wrote:
| 68K die was vastly too expensive for those 8-bit markets
| way into the late 80s.
| Someone wrote:
| From that article: _"In comparing measurements remember that
| SANE calculates to 19 digits. BASIC to 9 and Pascal to 6"_.
|
| SANEs claim to fame wasn't that it was fast, it was that it
| produced results accurate to 1/2 ulp
| (https://en.wikipedia.org/wiki/Unit_in_the_last_place) in a
| large (for the time) floating point format.
| brucehoult wrote:
| That is a completely ridiculous suggestion.
|
| The hardware FPU on the 1954 IBM 704 took 60 us for addition
| and 300 us for multiplication.
|
| That is likely to be the slowest hardware FPU ever. The Intel
| 8087, for example, was about six times faster. I expect the
| optional FPUs on things like early PDP-11s to also be faster.
|
| AppleSoft BASIC has quick&dirty FP operations and uses about
| 1000 us for an add and 3000 us for a multiply.
|
| SANE is IEEE-compliant and has to be careful to get 0.5 ULP,
| round correctly, set flags etc and therefore I would expect it
| to be slower than AppleSoft. But I don't know how much slower.
| I never used it on a 6502.
| adrian_b wrote:
| Moreover, Intel 8080 and its derivatives, like Z80, where
| frequently much faster for floating-point operantions than
| 6502 derivatives, depending on their relative clock
| frequencies and on the speed of the memory.
|
| The main reason was that 8080/Z80 could do much faster FP
| multiplications (which were extremely slow on 8-bit
| microprocessors, typically requiring many milliseconds or
| even tens of milliseconds per FP64 multiplication), because
| those could be implemented by using 16-bit additions and
| 16-bit shifts and accumulating partial results in registers
| (i.e. by using the 16-bit index operations and registers, not
| the 8-bit accumulator operations). 6502 had only 8-bit
| operations and too few registers to keep partial results in
| them, so the partial results had to be stored in memory.
|
| Nevertheless, the great advantage of 8080/Z80 in
| computational speed was not always realized, because a lot of
| the 8080/Z80 programs used naive multiplication procedures
| that were an order of magnitude or more slower than the
| optimized multiplication.
|
| Even in the Microsoft BASIC and in the run-time library of
| the Microsoft FORTRAN compiler for CP/M the floating-point
| operations did not have an optimum implementation, so after
| reverse-engineering them and replacing the core algorithms I
| could speed up a lot my programs in MS CP/M FORTRAN and
| BASIC.
|
| The AMD floating-point peripherals for 8080/Z80, Am9511 and
| Am9512, which were second sourced by Intel as 8231 and 8232,
| were faster than achievable in software. They used a
| microprogrammed implementation, IIRC with a 16-bit ALU.
|
| Am9511/Intel 8231 was not much faster than optimized
| software, but Am9512/Intel 8232 was much faster. However the
| latter was launched only in 1980, not much before Intel 8087
| and after the first discussions for the standardization of
| the Intel 8087 FP formats, so Am9512/Intel 8232 was actually
| the first hardware FPU to implement them (i.e. the future
| IEEE 754-1985 standard). Since 8087 was available only for
| 8086/8088, 9512/8232 remained the solution available for
| 8080/Z80, but I doubt that many have used it, because whoever
| had money to pay for an expensive FPU would have been likely
| to also pay for a better 16-bit CPU, instead of staying with
| Z80.
| jcmeyrignac wrote:
| Here are a few other 6809 FP libraries:
| https://gitlab.com/dfffffff/fpo9
| https://github.com/spotlessmind1975/ugbasic/blob/main/ugbc/s...
|
| If I remember correctly, the ROM of MO6/TO7 contain also a fast
| implementation, but I was not able to find a disassembly.
| spc476 wrote:
| The first link is to the MC6839, which is covered already in
| the blog post. The second link is the Lennart Beschop's
| floating point routines, which is what the post is about.
|
| > ROM of MO6/TO7
|
| Do you mean the MC6839 here? Or something else?
| jcmeyrignac wrote:
| The MO5/MO6/TO7 were based on the 6809:
| https://en.wikipedia.org/wiki/Thomson_MO6
| https://en.wikipedia.org/wiki/Thomson_TO7 Since I met the
| engineers, I believed that they implemented their own Basic,
| but I might be wrong.
| itishappy wrote:
| Bit of a tangent, but I'm curious what people make of the
| obligatory picture.
|
| https://www.conman.org/people/spc/about/2024/0802.html
___________________________________________________________________
(page generated 2024-10-18 23:02 UTC)