Theo Verelst Diary Page

Latest: March 7 2001

I've decided after good example to write some diary pages with toughts and events.

Oh, in case anybody fails to understand, I'd like to remind them that these pages are copyrighted, and that everything found here may not be redistributed in any other way then over this direct link without my prior consent. That includes family, christianity, and other cheats. The simple reason is that it may well be that some people have been ill informed because they've spread illegal 'copies' of my materials even with modifications. Apart from my moral judgement, that is illegal, and will be treated as such by me. Make as many references to these pages as you like, make hardcopies, but only of the whole page, including the html-references, and without changing a iota or tittel...

And if not? I won't hesitate to use legal means to correct wrong that may be done otherwise. And I am serious. I usually am. I'm not sure I could get 'attempt to grave emotional assault' out of it, but infrigement on copyright rules is serious enough. And Jesus called upon us to respect the authorities of state, so christians would of course never do such a thing. Lying, imagine that.

Previous Diary Entries

March 7, 2001

Short report on relevant installation.

What's gnu, anyway ?

I don't remember if it is an acronym or short for something, it's pretty well known for quite some years as a certain type of license for public domain software, in terms of the compiler associated with delorie, which is known as a versatile, professional compiler and development environment in open source form, that is after more modest starting phase (I think) up to making high quality programs, I think also for pentiums and with quite some optimisation options, most common libraries, C++ and (as I now found) Objective C front end libraries, and in general quite a weight. I'm not completely sure but I think it is even without much modification the compiler that makes linus programs from their C sources, except in later versions.

I got the 1.3 or so version, anyhow not version two, mainly because some files from 2 don't fit on a floppy disc. Earlier I did some of the string simulations and the sample processor program on some version of gnu, I don't remember which one, I did use rhide at the time, a user interface shell in dos graphics. I wanted sockets at the time, on windows 95, which is currently not an option, so I switched to the cygnus evironment which also is based onthe gnu compiler, but a much more unix like development environment, and a dll/library with unix libraries mapped unto window facilities, which makes it like developing on unix, while the results run on windows, which works pretty good for many command line programs I tried, and in the end with a later cygwin version even for a full blown directX application.

The gnu thing for certain is serious, and it runs now, doable compilation times for a few modest tests I ran, so at least the compiler isn't much in the way of at least command line programs, which is a starting point.

I just ported the program to dump a audio sample to the synth microcomputer, which works decently it seems. I'll look at the waveguide and the wav write library later, thats good for a sample example page.

I should still get the graphics and the info doc files, to have at least some graphs, and 'info' based library and language reference, maybe try a few C++ things, even objective C is available, though I don't see too much use for that now.

I saw there are quite some pc based libraries, and even found that the blast library and sources are available, also for gnu, that could be worth a look, from what I remember thats a profi library with linear algebra functions in it, quite extensive and optimized. I talked to a person that was involved in it on a HP 'internal' symposium in germany years ago, from what I remember, if it is the same library, it is worth a look.

March 9, 2001

I though I'd make myself usefull at least

Function pointers and objects

I got the gnu, lets check, 112m4 version running, and it spins out programs that seem to work. Just to get the subject out of the way, I did some function pointer testing, which works fine under this compiler, the prototypes are checkes over pointers as well, but can be cast into what is needed, and I thought I would do a basic OO sys, just to make sure I got it in my fingers, still.

So I made an object structure, made some functions for some basic methods, included some memory stuff, and now I can do objects, in run time, create 'children', use the print or some other methods to deal with some of their content, loop over a liked list of them, and show how structs can be accessed at least without error thus far in such programs.

Fun enough? For maybe half a day work, fun enough, though normall not so much a target when there is no good purpose or serious money involved, at least it makes me clear I got this stuff up and running, from-the-hart, and ready for rapid and thus far as it seems unbuggy use.

How does that work? FOr non-programmers, I guess this stuff is hard to understand, though the idea can be seen as making little pieces of memory of the computer into a unit, composed of names subpieces, and that such units may point to other such units, and also can point to pieces of program instead of just data, which in turn can act on the content of such units.

So say we have a strucure with a name in it, maybe some data like a text or experiment data, or sound samples like in a wav file, we can look at such an 'object' as having its own 'methods' that can do something, such as printing its content. We'd then instuct that object to do 'print', and it would respond by a nice list of its content. For programmers, that on itself is not that special, except that the idea is that the object itself as a piece of memory contains both the data and the program pieces that make their methods work, or at least that the object points to the (normal programming language) procedures that perform what the object wants.

So we can see the object as sort of self contained, that is the idea underlying Object Oriented programming, not for no good reason, but there are various arguments that make clear that it is not necessaril ythe best way of looking at or implementing programming tasks. The next is that we somehow need to now where all objects are, and they can have relations with eachother, so we may want to introduce a certain structure.

For instance we may start with the highest object, and call it the root object, and define other as children from this object, and children or parents or equal line syblings of eachother. Also, we may want to be able to make a list of all objects existing, so they don't become 'dangling' or lost without our knowing they exist, so normally we'd make it possible to 'walk' over all existing objects somehow.

These ideas are the basis for the short OO program following, which in principle lets objects be created at will, put in a list without forcing slots, malloc their memory neatly enough, have methods defined as function pointers, for instance for a basic printing possibility, and who use programming techniques from decent enough and quite efficient C programming that could easily be made into some formal OO definition and function set.

Possible applications are not realy my concern, as I wrote it is just to get me and the compiler in proven enough mode of operation for this sort of core stuff on cruising speed. No beaty contest intention for this code, two warnings are not bad though, and obviously this is an experiment to test various programming principle every advanced C programmer should at least be thouroughly enough aware of, and as we know, C++ includes C.


#define INIT 0
#define PRINTOBJ 1
#define OBJREMOVE 2
#define ADDMETHOD 3
#define ADDCHILD 4
#define LASTMETHOD 5

struct obj {
   int id;
   char name[64];
   int (**methods)();
   unsigned char *data;
   struct obj *next;
   struct obj *parent;

struct obj ro;    /* Uninitialized instance of the root object */
struct obj *lastobj;
int lastobject = -1;
char message[] = "test message";

void f2()

void (*p)();
/* void (*pp[])(); */


int i;

int init(p)
struct obj *p;
   printf("init object\n");
   if (p->id < 0 || p->id > lastobject) p->id = ++lastobject;
   printf("init id:%d\n",p->id);
   p->data = message;

int print(p)
struct obj p;
   static int printcount = 0;
   printf("Method print\n");
   printf("Object id    = %d\n",;
   printf("Object name  = %s\n",;
   printf("Object data  = %s\n",;
   sprintf(message,"print %d",++printcount);

int objremove()

int addmethod(p,f)
struct obj p;
int (*f)();
   printf("Method addmethod\n");;

struct obj *addchild(p)
struct obj *p;
   struct obj *r, *w;
   int c;
   if ((r = (struct obj *) malloc(sizeof(struct obj))) == NULL) { 
      printf("Object allocate error\n");
   r->parent = p;
   r->next = NULL;

   while (c++<100 && (w = w->next) != NULL) while 
   if(p->next == lastobject-1) p->next = r; 
   lastobj->next = r;
   lastobj = r;


#define STDMETHODS { init, print, objremove, addmethod, addchild, NULL };
int (*stdmethods[])() = STDMETHODS;
int (*pp[])() = STDMETHODS;

struct obj *p;
int c;
   int j;
   p->id = c;
   if (c>lastobject) lastobject = c;
   for (j=0; j<=LASTMETHOD; j++)
      p->methods[j] = stdmethods[j];
   p->data = (unsigned char *) p->name;
   p->parent = p;
   p->next = NULL;

   int j;
   lastobject = 0;
   lastobj = &ro;

   struct obj *test;
   int c;
   printf("obj 0: ");
   test = (struct obj *) ro.methods[ADDCHILD](&ro);
   printf("parent = %s",(test->parent)->name);
   test = (struct obj *) ro.methods[ADDCHILD](&ro);
   test = (struct obj *) test->methods[ADDCHILD](test);
   test = (struct obj *) ro.methods[ADDCHILD](&ro);
   test = (struct obj *) ro.methods[ADDCHILD](&ro);
   test = &ro;
   c = 0;
   printf("descendents of %s\n",test->name);
   while (c++<100 && (test = test->next) != NULL) printf(" #%d  id %d: %s, parent: %s\n",c,test->id, test->name,(test->parent)->name);

   p = &f2;
   pp[0] = (int (*)()) f1;
   p = (void (*)()) &f3;

   ro.methods[0] = init;

The result is a handfull of objects printing their contents after they are created, and the last bit is a list of all objects stating their name and their parent.

Method print
Object id    = 5
Object name  = Object5
Object data  = Object5
descendents of obj0
 #1  id 1: Object1, parent: obj0
 #2  id 2: Object2, parent: obj0
 #3  id 3: Object3, parent: Object2
 #4  id 4: Object4, parent: obj0
 #5  id 5: Object5, parent: obj0

As clear from the list and the source code where the method to call a add a child is called, most object instances reside directly under the root object, while one (3) is a child of another (2).

No problem.

Whats the point? Apart from at least making clear this not problematic and that I know what it is about, there is point I've been quite aware of when I programmed quite a bit of Objective C, that the OO paradigm makes only limited sense. The function pointer idea for instance may be of use, and a list of methods per data unit is a fine enough idea, but every pointer is 4 bytes or so, and taking the object to another place in memory may be fine, but that would work just the same with normal programming rules on tradionally formatted data, if done with continency, the idea I do find amusing in tcl, and formerly (way formerly, on a acorn electron 15 years ago) with LISP would be to have the actual code available in an object, and be able to transfer it around, for instance over machine boundaries, which is hard for normal programming languages that are compiled, tough it would be possible for homogeneous machines, sort of like in Java, where the virtual machine idea makes that work.

For the rest, there is nothing against simply recording which datatypes one wants to use, and make some mapping between a library of functions and the various datatypes, and then there are quite some alternative possibilities, often a lot more data and possibly access efficient.

Ideawise it is fun to type a message to some object, which then responds by applying the method called for, and maybe promting other objects. SOmetimes it is of use, because such a structure can be implemented without needing to think too much, so with less programming effort.

Apart from such considerations, there is no added actual programming strenght, no processes, threads or streamed data access, and not that strong a library, except that indeed for making graphics objects for instance for a disc structure, the idea like above has a programming and implementation appeal, its a decent enough ordering and memory layout of data and structures in it and the functions that access it.

Enough about that, so this works, now what? I don't know for sure yet, I think I should get the gnu graphics libs to at least get those few colors of dos lines, and the info tool with some more than just libc help files should be good. I don't think I'll go bash, maybe rhide would be nice, but command lines with the aid of norton for command line editing and some history can work.

I've peeked at some interupt based sources for timers and such, and maybe it could be of general enough use to do some multithreading, pushing it a bit to do so with interupt driven pre-emptiveness, while not having linux or so that at least should be good enough for some progress and a nice combination with some block editing stuff, textual and maybe simple graphical, with streams as I made them before it might be strong for synth simulation infrastructure, depending a bit on the granularity I'd want the preemtiveness may not be a good idea, but that makes it possible to multitask something, which is usually fun enough.

More pins have more fun ?

I found a thrown away motherboard with a pentium 133/166 on it, an intel one, with pci chipset, controllers and such, except no memory simms or dims, just empty slots. The pentium has got a good socket, one never knows why the thing was thrown away. It doesn't run without memory, or for other reasons. Would these be basic memory?

um 61 L 3264 F6


PCIset 882438VX

The second looks like cache ram, I had one of those some time ago when I did logic analyzeer things with some fast counters and a 15nS or so ram like it, that works.

Lets see what questlink sais.