[fpc-pascal]DXE demo uploaded

Marco van de Voort marcov at stack.nl
Fri Jul 20 17:08:32 CEST 2001

> > I'm playing with DXE a bit, and got it working nearly straight away.
> Rather interesting for me as well, thanks!
> However, I have several questions

No problem.
> > Some points about DXE:
> > 
> > - The code loaded has to be totally self contained, and a unit. 
> Does this mean that:
> (a) it can't be linked with other DXE's

Only via the mainprogram (passing pointers around via the mainprogram)

> (b) it can't be linked with ANY other code (i.e. no "USES")
> ?

Not yet. I'm still studying for a way to do this runtime, and for that I have
to fully understand the COFF format. This won't happen overnight.

> > You cannot
> > call any RTL procedures directly from the DXE, you can also not 
> This means 'no SYSTEM unit', I suppose...

Not direct. Only by loading them into DXE global variables just after
initialisation. Pretty much like the STACKCHECK example.

> > call DXE
> > directly from the mainprogram.  However the mainprogramma can 
> Pardon? I can't understand this, adddemo.pp has a direct call to the 
> DXE...

I stated it not really clear:

You can call directly, but there is no direct binding. 

> writeln('5+6 =',addfunc(dxe_load('add.dxe'))(5,6));

This isn't entirely direct, since mainprogram routine "dxe_load" returns a
pointer, which is typecasted to type "addfunc", and indirectly executed as a
procedure variable.
> > pass you
> > pointers to e.g. GETMEM and FREEMEM so that you can 
> > allocate/deallocate memory. Don't forget that a lot of actions 
> > (string manipulation, exceptions
> > using int64 etc implicitely call RTL procedures)
> > One can in theory link the needed RTL functionality in the DXE.
> > - One can only pass ONE pointer from the DXE to the main program 
> > on load.
> How is this passed?

As return value from the dxe_load procedure above.

This could be a pointer to an array of pointers to a lot of procedures though.

Or a procedure that somehow gets pointers from the mainprogram to the DXE
via parameters.

> >  Nothing more. I'm studying on a system to enhance this at the 
> > moment.  For the experimentors: Let this pointer point to a 
> > structure or function
> >  that can return more pointers to structures and functions.
> >  Via parameters to such functions, you can load global variables 
> > in the 
> >  DXE with needed RTL functions.
> Two more related to this, about dxe_load, when I call it, the DXE is 
> loaded, then executed, then it disappears from memory?

No. Unloading is not yet possible, but not hard to implement. In the future
it can be removed from memory, but that will require an explicit call.

IOW you can load an DXE, make as much calls as you want, and kill it.

If the DXE allocates heap (via het mainprogram), it will be allocated even
if the DXE unloads.
> If the answer is (or can be) NO, if I start two procedures of the same 
> DXE unit, are they sharing these global variables? 

Yes, and units in the DXE can call eachother normally, and do all the normal
stuff. In fact you are loading a kind of second exe.

> Or are different 
> instances of the DXE unit loaded in memory, so that these variables are 
> newly created for every instance?

No. The DXE also doesn't create anything. It can't contain startup code.

> If yes, is it possible somehow for the DXE to keep in memory some 
> variables that can be shared by everybody? By everybody I mean:
> (a) all the procedures of the DXE
> (b) the main program that calls the DXE
> (c) every program that is 'EXEC()'-ed from the main program?

Exec() is a differnet memory space. The main program can access DXE variables,
but doesn't know where they are. The DXE has to provide the mainprogram with
pointers to the variables.
> And a final one, I have seen this in your BAT program:
> dxegen add.dxe _ADD$$_ADDNUM$LONGINT$LONGINT add.o
> do you have to declare every function? If so, where can I read about 
> the data identifiers (e.g. LONGINT) that are used in this declaration?

You can use -a and see the names in the .s file.

However at the moment the DXEGEN program is still a C program. I converted
it to Pascal (still have to test it), but probably we can slip in some more
sensible way of doing this.

.DXE's also have the disadvantage that they need some memory to initialise
(and relocate).

More information about the fpc-pascal mailing list