Current State

Hans-Dieter.Dreier@materna.de Hans-Dieter.Dreier@materna.de
Tue, 10 Aug 1999 11:09:15 +0200


--ZWQ6AsPqAzBJrtp7PUcKv5RBCxIoE1o4
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable


Hi all,

I'd like to let you know that I'm still alive and have been busy in my rare=
 spare time.
I'm been working on an implementation of the object model I sketched in sev=
eral postings.

Current state of affairs is:

- Object loader (ie "object assembler", see postings) is working.
  It takes a text file and produces memory objects similar to the ones
  described in "PS: Memory Layout Proposal".
- A memory dumper is working.
  It takes an object space and produces a text file that is suitable
  as input to object loader
  (except that you may have to add some constants declarations).
- I'm working on the virtual machine.
  This needs a stack class for the operand stack, which is implemented but =
untested,
  and several auxiliary classes which exist partially, but still lack funct=
ionality.
- I'm trying to remove the STL template stuff I'm currently using as a quic=
k fix.
  My compiler produces the weirdest error messages on any mistake and
  it is really hard to figure out what went wrong and where it went wrong.
  It's a pity, but IMHO it causes more trouble than it's worth.


I tried to upload a zipped version of the source code + generated doc + doc=
 generating tool (Autoduck) on June 22 but it bounced due to a size restric=
tion (100kB).
Without Autoduck.exe it would be small enough but the bounce reply stated .=
..

> The project has the mailing lists on the proviso we
> don't send code through it, sorry, I will send a message clarifying this
> as I didn't mention it earlier.

> Try putting it on the web or ftp or something if you can ... I'll see if
> I can get a cvs server shortly.

Well, sorry, I got no web site or ftp server to put the stuff in,
so I'll wait till one of you comes up with a solution.


BTW, I'm also rethinking the extensive use of object orientation. Here an e=
xample why:

//@class MC | Helper class to represent an entry to machine executable code=
.
class MC {
public:
	void (*mpCode) (VM&);		//@cmember pointer to executable code
	//@cmember Constructor
	inline MC (void (*pCode) (VM&)) : mpCode (pCode) {};
	//@cmember Operator() - Call MC code with correct parameters
	inline void operator() (VM& pVM) {(*mpCode) (pVM);}
	inline bool operator!=3D (Pointer p) {return p !=3D (Pointer) mpCode;}
	inline bool operator=3D=3D (Pointer p) {return p =3D=3D (Pointer) mpCode;}
};


I thought it might save some typing effort to introduce a helper class like=
 this to implement pointers to functions which all have the same parameters=
 and return values.
First problem was pointer comparisons.
Well, OK, I added operators to the class to fix this. Then I wanted an arra=
y of these:

//@globalv Array containing references to all the MCs defined in this execu=
table.
// Offsets of entries should always stay the same.
// End of array is detected by single NULL entry.

MC gMCArray [] =3D {
	MC_Trap,
	MC_Exit,
	NULL};

During debugging I then had a look at the assembly code generated by this d=
eclaration and I was slightly horrified.
If it would have been C, this declaration would not have produced a single =
executable instruction, just bare data.
But the C++ version that uses the helper class produces 50 bytes of code to=
 perform this declaration and does not even inline the simple constructor w=
hich is another 50 bytes.
I must admit that it was a debug build, however. 630 KB for the exe file. B=
ut even 120 KB for the release build is a lot.
Small wonder "modern" software is so big.
So what is the essence of this?

OO is nice, =

but has its price.

Sometimes it might be better to use old fashioned macros instead of all thi=
s fancy stuff
(though in principle I don't like macros either).


--

Regards,

Hans-Dieter Dreier
(Hans-Dieter.Dreier@materna.de)=

--ZWQ6AsPqAzBJrtp7PUcKv5RBCxIoE1o4
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

IDENTIFIKATIONSANGABEN:
a13752a.txt IA5 DX-MAIL X.400 User Agent=

--ZWQ6AsPqAzBJrtp7PUcKv5RBCxIoE1o4--