Other Mandelbrot set renderer written in pure Makefile.

baaz

baaz

github.com

GitHub - b-aaz/bmake-extravaganza: Pushing BSD-make to places it was not designed for.

Pushing BSD-make to places it was not designed for. - b-aaz/bmake-extravaganza
github.com github.com

This is a Mandelbrot set renderer, written in pure BSD Makefiles, with no calls to ANY external binaries.
This project started after I was reading a bunch of the port system's Makefiles, and I realized that the language is actually computationally universal, so I had to write something to try it out, and here we are!

1783175204940.png

I was on the edge on putting this in this sub-forum or off-topics, I hope it is OK here.
 
This is very cool. Bookmarked to present next time someone says Make is too restrictive ;)

My general statement about make is that it can always do exactly 99% of the task required but no more. And that last 1% is a massive ugly pain in the butt. With your experience of this project, have you noticed similar?
 
Code: 
root@Z600:~/code/bmake-extravaganza # cloc .
      30 text files.
      28 unique files.                             
      10 files ignored.

github.com/AlDanial/cloc v 2.08  T=0.04 s (720.5 files/s, 74369.4 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
make                            27            114            194           2473
Markdown                         1             13              0             96
-------------------------------------------------------------------------------
SUM:                            28            127            194           2569
-------------------------------------------------------------------------------

👏👍😎
 
kpedersen said:
This is very cool. Bookmarked to present next time someone says Make is too restrictive ;)

My general statement about make is that it can always do exactly 99% of the task required but no more. And that last 1% is a massive ugly pain in the butt. With your experience of this project, have you noticed similar?
Click to expand...
This project was basically just delving in that 1% XD.
Floating point arithmetic, infinite loops, arbitrary calculations ...

But bmake also has some hidden, unique, solutions for some problems, I for one didn't know that you could print out a variable cleanly to stdout, mid-parsing, by mixing the -v flag and .MAKEFLAGS: special target, I learned that while doing this project.
The "dot-prefix" special targets and variables are definitely a great and IMO underrated tool.
 
doul said:
2473
Click to expand...

To be frank, 900 lines of that is the reciprocal initiation table for division, 100~ lines for the multiplication table, and 400 lines for the addition and subtraction tables, so there would be about 1000 lines of actual logic code.
 
Actually, we are entering in the software implementation of floating point arithmetic, which is highly enthusiastic.

The question I ask myself is why don't use everywhere the same layout: number = sign.mantissa.10^-scale ? This will standardize the API and make precision explicit and easily tunable with the size of the mantissa. I thought using a fixed point would upgrade efficiency for hot Mandelbrot paths.
 
doul said:
Actually, we are entering in the software implementation of floating point arithmetic, which is highly enthusiastic.

The question I ask myself is why don't use everywhere the same layout: number = sign.mantissa.10^-scale ? This will standardize the API and make precision explicit and easily tunable with the size of the mantissa. I thought using a fixed point would upgrade efficiency for hot Mandelbrot paths.
Click to expand...

If I wanted to do something similar to a virtual ISA I would go with a IEEE 754 system, but that would be super slow and unnecessary for this project:
  1. Each multiplication/division would need another bit of decimal arithmetic for calculating the resulting exponents. While currently it is done with a simple dot shifting system.
  2. Adders would also need a way for scaling the numbers properly based on the decimal number of the exponent and they then needed to cut the result down to size. (super slow)
  3. You would have to create pre-filled lists, based on the chosen size, for the key .for loops going over the digits of the mantissa in different hot functions. That would also slow down those loops slightly, which would add up.
  4. You would have to make sure this system also works with bmake's arithmetic conditionals (which it doesn't) or you would also need to write your own comparison functions, which would also be super slow.
To see why 16 was chosen for the current number size run the code below:

Makefile: 
a=98
b=99
.for i in 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
. info \# $(i)
. info $(a)
. info <
. info $(b)
. if $(a) < $(b)
.  info TRUE
. else
.  warning FALSE
. endif
a:=$(a:S/9/99/)
b:=$(b:S/9/99/)
. info $( :L)
.endfor
all: .PHONY
 
You must log in or register to reply here.
Back
Top