Hello all,

I'm not sure how well received this sort of thing would be in assembly but I've been putting together some generic data structures and algos using FASMs very powerful macro systems.

That way it works is that you write code for say a linked list and instead of trying to make it reusable by having node contain pointer to the data they hole, instead the data is stored directly in with the node and the templates generate different functions specific for each type of data.

The real advantage of this is in algorithms where instead of relying on callbacks functions to deal with different data types the macros generate a specific version of the algorithm for each type of data. This avoids the overhead of callbacks which can be particularly bad because they require indirect calls (well I think they do).

The problem is though that Iíve had to make too many design decisions, and quite frankly Iím just not experienced enough to be making them. So while Iím not abandoning this little project, Iím just not sure how much further I can take myself.

I encourage people to check out the quick webpages Iíve put together, in particular read the design decisions page which describes some of the problems Iíve come across.

Also look at the source and ask questions about what is going on internally because I havenít documented that yet.
Posted on 2005-09-08 12:59:13 by Eůin
I am just wondering, are you going to put in place ADT like queues, priority queues, etc etc. By the way, your code do look very c++ish.  ;)
Posted on 2005-09-08 21:59:57 by roticv
Hello roticv,

Yes Iím sure everything does look like C++, but Iím not trying to hide the fact that I was motivated by C++ís STL and adopted its names for alot of things..

I think most people will agree that assembly needs some sort of standard library with prewritten data structures and algorithms. While nothing will be best in all situations, there is a best for a lot of situations. If that is already implemented and tested then new programmers will and indeed most programmer will find their lives a bit easier.

The problem with writing a one data structure fits all is as I've explained is that it tends to overly rely on pointers and callbacks which needlessly bloat and slow things down. This generic technique with macros tries to avoid that, but it does have its own problems as Iíve mentioned above.

So to answer your question, will I be implementing more advanced types? I would like to but amn't sure if I will. Thing is that I donít consider myself qualified or experienced enough to be making the though decisions I've described above. And if the wrong choices are made there the rest of the work could but made redundant.

That is why I posted this so early in this development, I need some help or advice on it.
Posted on 2005-09-09 07:10:37 by Eůin
Its safe to bet that not many people are interested in this. Perhaps Iím not surprised, it does seem very HLL.

I wonder though is there a better way of writing a reusable library of data structures and algos? Almost every program needs some sort of dynamic array or a means of connecting keys to some sort of data through an associative map of some type. Well at least all of my programs seem to need those things.

I canít think of a good way to implement such things which will be reusable.
Posted on 2005-09-14 12:54:15 by Eůin
My approach is to keep my own source code lib and do "copy+paste" but that's too betov and probably not acceptable by most. The problem with code reusing is that you are trading it off for speed and size which is essentially what coding in assembly is about.

Maybe we can get a library of graph algorithms and so on. Haha.
Posted on 2005-09-14 13:05:45 by roticv
It is of course true that a trade off can't really be helped. But as assembly is becoming more popular there is surely a need for well written and tested code libraries (not that I'm suggesting what I wrote above is either of the two :) ).

Even a source library would be difficult to make easily reusable for a varity of type unless you enforce some limitations on yourself which will probably sacrifice size and speed too. The macro method is kinda a source library isn't? Just one whos insides don't have to be understood if you don't want to.
Posted on 2005-09-14 13:25:47 by Eůin
Yes, you are correct. Personally I support your project (seems like I am the only one interested), but I do not exactly know how to answer your question on whether your decision is right or wrong.
Posted on 2005-09-14 23:19:31 by roticv
It's an interesting project - I have a set of MASM macros that do the vector stuff, and they prove very handy.
Though, I have 3 types of "predefined" vectors (realized as OOP objects) :
ObjVector (most often used) -  holds dword values, most often pointers or handles
has a "foreach" macro - thread-safe, and foreach-like macros (both thread-safe and not)

HookVector - extremely useful for callbacks. Here objects register themselves for events, instead of the event procedure sending the event to all objects created.
has a "CallHooks:Param1,Param2" method for event processing

VarVector - holds objects of arbitrary size (each object can have a different size), has a "foreach2" macro. Created it on request of my OOP-model users.


The first two vectors prove very efficient in making (large) software quickly and safe.
The TDword-template probably will be the most often used, I think. Maybe adding qsort/heapsort proc with a custom callback function (for custom compare) could be good - especially when using pointers
Posted on 2005-09-15 04:22:49 by Ultrano
I think. Maybe adding qsort/heapsort proc with a custom callback function (for custom compare) could be good - especially when using pointers


That exact thing is what prompted me to try this generic approach. I have written two QuickSort/Insertion Sort hybrids. One which operates directly on DWORDs in an array. The second uses a callback function for comparing two elements. When run on the same array of dwords the callback method runs close to 2.5 times slower.

So I decided that since callbacks are too slow, and that rewriting a quicksort for each and every data type would be too awkard that maybe an approach with macros generating code for different data types would be a nice comprimise. Its very trick to do though.
Posted on 2005-09-15 07:56:37 by Eůin