Okay, I wrote a Mandelbrot calculating program. The important part is that it works. However, there are tons of features missing.... you can't zoom in (only render a massive image), I don't do error checking (uses the naivest str-to-int procedure you could think of ), there's a static buffer (how exactly do you dynamically allocate memory on Linux?), it unnecessarily uses 64-bit, it outputs a raw TGA file, etc.

Feel free to port it to 32-bit. I have a 64-bit system, so I didn't feel like doing it.

Important files are the mandel.asm and mpalette.inc file. LSCR package is included for the symbols.inc (it's useful!). Other files (PHP scripts etc) are helpers; mpalette.php generates the palette <gasp>, and mandel.php is the PHP version, which is slow and annoying, but is a nice reference.

Anybody want to help optimize?

It's licensed under the Artistic license, also included.

P.S. Please tell me if it doesn't work (can't assemble etc.) Remember, the image size limit is 4096x4096 (or 2048x8192, etc.), thanks to my limited knowledge of Linux programming.

P.P.S. Reading the README is recommended

P.P.P.S. Yes, if you look in the tarball, my username is goffrie; you've all been tricked!

EDIT: (i.e. P.P.P.P.S. ) New version, using sys_brk to dynamically allocate memory. Also, a little source code cleanup.

EDIT2: New 32-bit version. Old version is still here. Anybody know how to rename attachments?

mmap()

sys_mmap was a little too confusing for me. Instead, I looked into FASMLIB and how memory allocation was done there, which happens to be sys_brk; this fits very well with my previous scheme, so I use that now. Attachment updated!

UCM: but that works only if you need to allocate just one block at a time.

I only need to allocate one block, ever
I modified the code to be 32-bit. I now use a few FASMLIB macros and the ATOI procedure from Reverend. (I will be using ATOF soon, so it's included but unused.) I plan to use FASMLIB to make it portable to Win32.

I'm not a fan of sbrk(), been annoyed with it ever since DJGPP which used a similar method... mmap() allows for multiple allocs, more control, and won't interfere with e.g. libc.

But okay, it works if you'll only allocate one chunk of memory and never do deallocation or link with libc.

f0dder: sbrk has one advantage over mmap(). you can enlarge sbrk data block, without having to fix pointers. that is not case with mmap, such block cannot often be enlarged without moving it

You can only enlarge "an sbrk() block" (which is imho incorrect terminology because of it's implementation) if no other sbrk() calls have been made in the meantime.

You can't use mmap() as a replacement for HeapAlloc/HeapReAlloc, but you can't do that with sbrk() either - you need to allocate big chunks of memory and do arena management ontop of that, no matter which method you choose as the underlying big-chunk-manager...

yes, that is the disadvantage


yup... you need heap manager for that.

- if you need one block, sbrk is okay, and you can enlarge it without having to fix pointers
- if you need more blocks, mmap can be used, but you haveto fix pointers when enlarging blocks, and every block has page-aligned size.
- with heap manager you have to fix pointers too, but blocks have only few bytes of size overhead