84 karma · joined July 27, 2014
I'm an assembly programmer, but I've always wanted a CAD tool that combines the workflow of OpenSCAD with the ability to export true, exact geometry to STEP files, rather than polygonal meshes.
I found an abandoned project called bcad, which tried to use OpenCASCADE (OCCT) with OpenSCAD syntax. I decided to revive it. Since I don't know Python or 3D graphics development, I let AI do almost 100% of the coding. I used the terminal version of opencode with the Big Pickle agent, and it worked surprisingly well.
The GUI is built on Dear ImGUI. The app is fully portable (no install, just unpack and run) for both Linux and Windows.
Source code (Fossil): https://asm32.info/fossil/bcad/
The same is about the rebase - the difference is that while git keeps the history "as the developers want it to be", fossil keeps it "as it actually happened".
The big problem with using "gcc -S" is that as a result you have a HLL program, simply written as an assembly language listing.
The humans write assembly code very different than HLL. Even translated to asm notation, this difference will persist. Asm programmer will choose different algorithms, different data structures, different architecture of the program.
Actually this is why in the real world tasks, regardless of the great compiler quality, the assembly programmer will always write faster program than HLL programmer.
Another effect is that in most cases, deeply optimized asm program is still more readable and maintainable than deeply optimized HLL program.
In this regard, some early optimizations in assembly programming are acceptable and even good for the code quality.
apples and spice = nice
At first, FLTK, does not look much better than the old Windows widgets.
In addition, I strongly want Fresh IDE to be portable to MenuetOS, KolibriOS and other assembly written OSes. As a rule, they all are written with FASM and a good IDE that can be ported for days (not for years) can be great tool for the OS developers.
That is why I started the development of special GUI toolkit.
Unfortunately it will add another 50..100kB to the code, but the portability has price. :(
For example, I don't know Lisp, so for me it is much harder to read/maintain Lisp project than assembly language project.
Because allow the programmer to not think (and even know) about some things and leaving them to the layer/libraries.
But every layer adds also a level of obscurity. The interaction between multiply layers is even more undefined and random.
It is OK while everything goes as expected. But when there are problems, the obscurity can make the debugging a hell.
In addition, the behavior of the bugs hidden deep in the layers (or in the way the layers interacts in between and with the application) can be really weird.
That is why, IMHO, the programmer should keep the abstraction layers to the minimal count that allows solving programming tasks with minimal effort, counting not only the coding time, but debugging and supporting time as well.
In my practice, I decided that using FASM with Fresh IDE and set of assembly libraries gives me the needed quality of the code.
The code reliability of assembly programs is better because programming algorithms in low level, the programmer controls every aspect of the execution. Notice, that excessive use of code generation macros will cancel this advantage.
Another advantage is that the bugs in assembly programs usually cause immediate crash of the program and this making the fixing easy.
Defer crashes and strange/random/undefined behavior of bugs in assembly programs is rare. IMO, this is because of reduced count of abstraction layers.
But some documentation is available in the "Documentation" section of the web site and inside the "Help|Help file" (Ctrl+F1) menu in the IDE itself.
There are small example and template projects as well.
Also the FASM forum is a good place to ask: https://board.flatassembler.net
On the other hand, definition of complex data structures is much easier with powerful macro engine.
But the code is more reliable and the debugging process is much easier. After some short debugging stage, most of the projects runs for years without single bug report or other support issues.
I am not talking about the significantly higher speed, lower memory footprint and better UX (especially the response time of the UI is really much faster).
As a whole the advantages are more than disadvantages IMHO.
And most of they are application programming (Fresh IDE itself and many closed source projects in my work) or even web programming (https://board.asm32.info).
That is why I needed a powerful IDE, suitable for rapid programming of relatively big projects (500Kloc or higher).
Still not GTK though. It is too heavy for assembly language programming and will not allow portability for example on MenuetOS or KolibriOS assembly written OSes.
Also, there is a popup menu at left with the navigation links. Although, the repository interface is not very mobile friendly.
Thanks for the report!
The humans write assembly language in different way, because they are not limited by the HLL rules, only by the hardware resources.
I would suggest simply to take some good quality, human written assembly language source and to try to modify it to fit your needs. Or start to program some small assembly language program from scratch and ask on the asm forums for help.
I know that the performance can be improved by using some optimization tricks, but I simply don't need (for now) it to be faster. :)
Also, it is true, that x86 hardware can run much heavier web engines, but think about that the same hardware can run more lightweight engines as MiniMagAsm.
Anyway, the future of this project is probably towards using FastCGI or SCGI interfaces and maybe the use of some lightweight database engine - like SQLite.
Ah, BTW, http://asm32.hopto.org is actually my home desktop computer. :) Recently, the whole project has been moved to a commercial hosting: http://asm32.info