ewx | Entries tagged with mandy

It turns out that Apple’s assembler is rather buggy and I had to do this:

        // Compute zy^2
        mov     r14,r10
        mov     r15,r11
        .att_syntax // hack to work around bizarre bug in apple assembler
        call    square
        .intel_syntax noprefix
        mov     r14,rbx
        mov     r15,rcx

…if I wanted it to actually assemble my code. The first call to a named label was OK, but subsequent calls and branches were rejected. (Branches to numeric labels don’t seem to have provoke the same problem.)

I’ve continued hacking on my Mandelbrot set program.

Firstly, it’s gained the ability to draw Julia sets (which are associated with the Mandelbrot set).

( Wide image )

Secondly, the use of double limits you to around 50 binary digits after the point (all the interesting stuff has a magnitude of at least 0.25 or so, so the “floating” nature of floating point doesn’t really do you much good). Given how fast it is, it doesn’t take much frantic zooming before things start to go blocky:

So I’ve been working away on using fixed point arithmetic to achieve the same goal. To do this at any reasonable speed required assembly language, and now it’s working. It’s somewhat slower than the floating point version, but gives 96 bits after the point, i.e. it allows you to zoom in almost twice as far.

You can browser the source, or git clone it, via gitweb.

I’ve not written a nontrivial amount of assembler in over 15 years, but have over the past few days started doing some for a future version of my Mandelbrot set program.

A few random thoughts:

I did most of my assembler programming on the 68K, so the AT&T syntax preferred by gas (i.e. op src,dest) seems natural to me. But the AMD documentation uses the Intel syntax and turning everything back to front is mindbending, so I quickly gave up and switched to that.
Fortunately there’s a .intel_syntax directive, and I did some Z80 long ago, so the Intel order isn’t wholely alien.
The MUL instruction’s a bit lame, isn’t it? The 68K could multiply any pair of registers (or in fact memory, for the source) and store the result in any register. Intel/AMD’s MUL fixes the destination and one of the inputs.
I was disappointed to find that there doesn’t seem to be a high precision integer multiply (128*128->256 would be just the ticket) in the SSEn instructions.

(Click on the image for a full-size version.)

I first encountered this stuff in my teens, via computer magazines, a friend with shared enthusiasms, and James Gleick’s book Chaos. My first attempt was in BASIC on a Sinclair QL, and very slow; it was nowhere near finished even the following morning. I had a lot of fun creating a faster version in 68K assembler using fixed point arithmetic (16 integer bits, rather more than required, and 32 fractional bits, as I recall).

Since Benoit Mandelbrot’s recent death there’s been a lot of references to it online, and that inspired me to revisit it this weekend. The visible results are above, and my program (still very much a work in progress!) can be retrieved using:

git clone http://www.greenend.org.uk/rjk/git/mand

Read the README. You will need a Linux or OS X system with the GTK+ libraries installed.

S	M	T	W	T	F	S
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28

Richard Kettlewell

amd64 (addendum)

Higher precision

amd64

What I’ve been playing with

Profile

February 2019

Syndicate

Most Popular Tags

Active Entries

Expand Cut Tags