Human68k Floating-Point Benchmarks for the Sharp X68000

Writing a Human68k tool to benchmark floating-point performance is a practical way to understand what an X68000 can really do. The aim is not a spectacular score, but a repeatable measurement another enthusiast can reproduce. That requires care because the original Motorola 68000 has no built-in floating-point unit, while some X68000 installations use an IEEE 68882 coprocessor.

Software floating point and hardware-assisted floating point therefore represent different machines, even when they carry the same processor designation. Clock speed alone cannot explain their performance. Memory access, compiler support, operating-system overhead and the presence of an expansion board all influence the result.

Human68k provides the native software environment for the Sharp X68000, making it a fitting place for such a tool. A useful benchmark should state exactly what it measures, preserve its configuration and produce enough diagnostic information to distinguish a slow processor from a slow implementation.

Why the X68000 Needs a Careful Benchmark

The first decision is whether to measure software emulation, a 68882 coprocessor or both. A 68000 executing software floating-point routines performs many integer operations for each arithmetic result. Those routines may use processor registers, stack frames and library calls. Their speed depends heavily on the compiler and runtime library.

Hardware-assisted arithmetic has different bottlenecks. Coprocessor instructions still require data transfers and bus arbitration, so installing an FPU board does not make every floating-point operation independent of the host processor. Its clock, memory configuration and expansion implementation can all change the score.

The Australian second-hand market adds context to this work. Sydney and Melbourne collectors often trade X68000 equipment through specialist forums, auctions and personal contacts rather than mainstream retail. Hardware imported from Japan may attract GST, customs charges and return-shipping costs, making careful documentation especially valuable.

Before writing code, define the purpose: compare arithmetic kernels, compare different X68000 configurations or check whether an accelerator improves an existing workload. Each goal needs different timings. A mixed calculation of addition, division and square root can conceal more than it reveals unless the operation count and weighting are stated explicitly.

Designing a Repeatable Human68k Test

Choose workloads whose arithmetic behaviour is understood. Addition and multiplication can run in tightly controlled loops, while division and square root have different execution costs. Transcendental functions such as sine or exponential usually call larger software libraries and should be measured separately from basic arithmetic. The Human68k development notes can provide useful orientation before working with its toolchain conventions.

Define the output before defining the timer. Useful measurements might include elapsed microseconds per operation, completed iterations per second and a documented floating-point rate. Avoid presenting every arithmetic function as an equal operation. An implementation may count an addition and a division as one “operation” each even though the division takes considerably longer.

Then fix the conditions. Record the machine model, processor clock, memory configuration, Human68k version, compiler version, optimisation flags, warm-up runs and iteration count. Run the tool repeatedly and report the median as the representative result, with the minimum and spread retained for diagnosis. A short program with very fine timing will usually be less trustworthy than a longer batch measured with a documented timer.

An Australian bench brings its own variables. During a hot Brisbane afternoon, a box fan may run beside the machine and introduce background noise into a sensitive measurement. Australia’s 230 V mains and readily available USB power supplies also make it easy to overlook an unstable external supply. Record input voltage and test with the intended power arrangement before blaming floating-point code for unusual results.

Implementing Arithmetic Kernels in Human68k

A practical tool can combine a C driver with 68000 assembly for performance-critical routines. The driver handles arguments, timing and reporting, while the assembly kernel contains a small, auditable arithmetic loop. The usual development path uses a cross-compiler targeting the 68000, but its exact target names and linker scripts depend on the chosen Human68k toolchain.

Keep the kernel deliberately simple. This example measures dependent multiplication latency, with a runtime-provided factor making constant folding less likely:

static volatile double sink;

double multiply_chain(int iterations, double factor)
{
    double x = 1.0;
    int i;

    for (i = 0; i < iterations; i++)
        x = x * factor;

    sink = x;
    return x;
}

Use a separate throughput kernel with several independent accumulators if that is the intended measurement. Put division and square-root loops in their own functions, and preserve the returned value so the compiler cannot discard the work. Save the complete source and build configuration alongside the executable.

Timing needs almost as much attention as arithmetic. Use the timer facilities provided by the target environment, measure its resolution and subtract any unavoidable start-up or completion overhead. Keep each measured batch long enough to exceed timer granularity. Repeated runs should produce similar results; excessive variation points towards interrupts, background activity, unstable power or an unsuitable workload.

Expansion hardware can provide useful knowledge without becoming part of the timed kernel. The CE1B expansion bus guide illustrates how a practical digital I/O card was attached to the X68000 expansion bus. Such experiments are valuable for preservation, but expansion-bus timing should not be treated as identical to ordinary coprocessor performance.

Reading Results Without Misleading Claims

Begin with correctness. Run the same kernels on software floating point and the 68882, then compare representative values against known answers. Check relative error, but also examine rounding, overflow, underflow and exceptional values. The two paths may provide different precision or range behaviour, so agreement on ordinary inputs does not prove equivalence.

Present raw timings alongside derived rates. Microseconds per iteration are direct and easy to reproduce; iterations per second provide another useful view. A floating-point rate expressed in MFLOP/s is valid only when the operation count and the weighting of addition, multiplication, division and square root are clearly defined. Keep unlike workloads in separate results rather than merging them into an impressive but ambiguous average.

Emulators have a legitimate role. A cycle-based emulator can help compare algorithms before access to scarce physical hardware, and it may expose instructions that are inconvenient to test on a real machine. However, an idealised 68000 model does not automatically reproduce the X68000’s memory system, bus timings or optional coprocessor. Label emulator measurements as emulator measurements.

Australian Consumer Law becomes relevant when benchmark claims support a sale or advertisement. A performance claim must be accurate and not misleading, so state the tested machine and configuration rather than implying that a score applies to every X68000. Keep customer identities and serial numbers out of public results unless their publication has a clear purpose and an appropriate privacy basis.

Publishing Results and Keeping the Platform Alive

A publishable result should contain enough metadata to recreate it. Include the machine and CPU clock, memory setup, Human68k version, compiler and assembler versions, build flags, source checksum, timer source, warm-up count, iteration count and the number of completed runs. Retain raw output as well as averages, because an unexpected minimum or outlier can be more informative than a polished summary.

Local knowledge often travels through enthusiast groups rather than formal documentation. At an Adelaide meetup, carrying the tool on a labelled USB stick can be more convenient than asking every attendee to upload disk images. The community link collection provides routes into the wider X68000 community, where archived discussions and other people’s measurements can help validate a new result.

Compare configurations by what they actually execute:

Configuration	What it measures	Useful for	Main caution
Software floating point on a 68000	Compiler routines and integer instructions	Establishing a baseline	Library calls and helper routines can dominate
68882 coprocessor installation	Coprocessor execution and host-bus transfers	Evaluating FPU-equipped hardware	Results depend on the board, clock and memory timing
Cycle-based emulator	Approximated processor execution	Comparing algorithms before hardware access	The full X68000 memory system may not be reproduced
Hybrid real-and-emulated testing	Numerical agreement across execution paths	Detecting compiler or numerical errors	Emulator and physical results need separate reporting

Build a small, honest benchmark now, run it on the target system and publish both the tool and its configuration through the X68000 community. A benchmark earns its value when another person can repeat the measurement, understand the conditions and explain why a different machine produces a different result.