Made a 65816 target for the java_grinder byte code compiler. Mike posted a demo we used for testing stuff:
http://www.mikekohn.net/micro/apple_iigs_java.php

Right now there is a little bit of graphics API for the IIgs but not much else. However one may use inline asm like this:



Please visit the main project page for more information:
http://www.mikekohn.net/micro/java_grinder.php

Edit: forgot to share the Mandelbrot test I did on my shiny new W65C265SXB dev board:

That's pretty neat. I love the character Mandelbrot set drawing too.

I've been thinking about making a 32-bit code generator (with floating-point) for the 65816. The current generator also has a flaw in that long addresses won't fit on the 16-bit Java variable stack, so programs are limited to the first 64k.

The integer routines will be easy, as I already did 6502 in 16-bit and most of that will translate over to doing 32-bit on the 65816. But having never implemented floating-point math before, I'm looking for wisdom. All that is required is add/subtract/multiply, and division with remainder. Can anyone recommend books/links?

If it helps, here are the generators for 6502/65816. Basically each function implements a bytecode instruction:

https://github.com/mikeakohn/java_grind ... /M6502.cxx
https://github.com/mikeakohn/java_grind ... W65816.cxx

You could try Woz' routines from 1976 - Jeff Tranter put them on github at
https://github.com/jefftranter/6502/tre ... /asm/wozfp

There's also a BCD-based floating point package by C R Bond, see
viewtopic.php?f=2&t=2202

Either of these might need some testing and attention - in the case of Woz' routines, there might be published errata.

Edit: Hmm, these could surely be improved for the 816 - maybe even change the formats to help. A byte-orientated layout won't work as well as a 16-bit word-oriented layout.

From my links page:
many math routines in 6502 assembly on the Codebase 64 wiki
Codebase 64: Commodore 64 source code, articles, tutorials
CORDIC algorithms for FPGA-based computers (.pdf). This link has the same article)
IEEE floating-point standard (.pdf)
IEEE-754 floating-point standard for arithmetic (Wikipedia)
IEEE floating-point conversion page
6502 BCD floating-point scientific math package, 12-digit plus 3-digit exp, up to hyperbolic functions
math coprocessors, 32-bit floating-point, serial-interfaced

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I seem to recall seeing Woz's code published somewhere around here as well.


At one time, I looked at implementing Woz's FP stuff on the 65C816 but set the idea aside for two reason. Fully adapting the code to the 65C816 would almost require a rewrite, as merely running the code as is on the '816 would gain little to nothing. Also, the code would become somewhat cumbersome, as constant switching of the accumulator size in order to take advantage of 16 bit operations would be necessary.

The other reason is Woz's FP format is limited to no more than seven significant digits, due to the use of a three byte mantissa. Also, ASCII to binary conversion errors of fractional content will be a problem.

My humble opinion is that it would be more profitable to implement IEEE double-precision on the '816, not a simple feat, but not as onerous as it would be on a 65C02.


I've tried out that one but it's not very speedy. I don't think trying to run a graphics program using FP BCD would work out well. However, being BCD, it does eliminate ASCII-FP conversion errors. 1.2345 ends up being 1.2345.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Quite so, Woz' routines and others can be found at:
http://6502.org/source/#floatingpoint

For the 816, instead of 3 (or 4) bytes of mantissa and one byte of exponent, I'd suggest two (or three) words of mantissa and one word of exponent, with judicious placement of the two sign bits. Try to avoid switching widths. The existing code would be a guide to the algorithms needed. For fractal purposes, you might want a much wider format, or even an extensible format - something like a counted string. I wouldn't use IEEE format though.

I wouldn't recommend BCD at all - it doesn't have the attractive characteristics that proponents think it has. And it's always going to be slow.

Back to an earlier question:

I'm not sure "remainder" means anything when you're in floating point - have I misunderstood?

If you want to go with a more modern definition for floating point then look at SoftFloat

http://www.jhauser.us/arithmetic/SoftFloat.html

Someone did a (partial) conversion for the pic years ago

http://picfloat.sourceforge.net/

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Thanks for the pointer.



Full IEEE is quite a handful...

It is. Its not unusual for 8-bit implementations to leave out the signed zero, infinities, NaNs and rounding -- just using the basic float layouts and precisions, although QNaNs can be quite useful.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

I misspoke. Integer divide algorithms were on my mind which typically provide the remainder. Java supports floating-point remainders, but nothing special is required for that.

After catching up on all the reading (thank you), I'm bewildered by the number of options. I think I'll start off easier and try to add 16-bit float support to the existing code generator, which is probably enough for game or microcontroller projects anyway.

Why not just adapt the relevant code from EhBasic?

That sounds like a very interesting little project. Too bad I already have too many pans in the fire, or I would have a go at a version with a 16-bit exponent and a 32-bit mantissa (48-bit float). I have my own unfinished implementation for 32-bit and 64-bit floats that has provisions for a single 0.0, a single NaN, +/- infinity, and +/- infinitesimal. It is completely symmetric, and allows integer negation and integer signed comparison to work correctly on my floats without modification. Obviously non-standard ... but so am I.

Mike B.

my 2 cents and maybe a little off topic...

Every once in a while I come across some proof that 1 = 0.99999... It goes something like this: 1/3 * 3 = 0.9999...

I usually respond that it depends on what number BASE you are using i.e. if the above example was using BASE 3, 1/10 * 10 = 1. I never get back a response to my response. BTW number theory give me headaches and I like math but dislike arithmetic.

Andy W.

The "..." notation for numbers does sometimes get people confused. As you say, 1/3 * 3 is obviously exactly one.

To write a good arithmetic package you'd really have to understand arithmetic very well. It's esoteric, but for amusement see John Gustafson's "Unum" idea, which adds one bit to floating point numbers to signify "..." which he finds to be an enormous improvement: https://www.youtube.com/watch?v=jN9L7TpMxeA [slides and transcript here] (He's also written a book on the subject.)