|Pliant announce forum
This debate has been automatically converted from the old Pliant forum
|Message posted by maybe firstname.lastname@example.org on 2000/01/17 09:01:09
|I've put release 31 on the net.
It contains over 300 typo changes (suggested from Gordon)
so that the core language should now start freezing a bit,
and some fixes that should enable Ben to compile using VC++.
I have not included Gordon 'enum' type constructor, but I
will, at the time I will finish the basic data types that
are still missing.
Ben, when you've applyed the changes that enable to compile
using VC++, email me compressed tree back so that I can
include them in the main tree.
There is another good suprise for you Ben: you can load
Pliant DLL from another C or anything else program, and
get a .dump file loaded, so you can implement your
interface, but it's very late for me, so more details after
|Message posted by maybe Ben Cooley on 2000/01/17 12:49:48
Still seems to be locking up during a rewrite somewhere.. I'm trying to nail down where.. but it's really almost impossible for me to do it without being able to decipher the pliant c code base.. which is really extraordinarily opaque.
Basically the changes for _MSVC_ are the use of the Interlock functions in the atomic operations (you should almost certainly use these in WATCOM and Windows GCC as well, as they are garanteed portable and garanteed to work.. also I think they are compiled as intrinsic functions in MSVC (compiled direct to inline asm like strcmp and memcpy).. though I'm not completely sure. (Funny having to code intrinsic functions into the compiler.. seems so quaintly archaic now that we've used Pliant for a while..)
For your info.. the interlock functions are described at..
These correspond directly to the atomic functions.. I'll send my source by e-mail.
|Message posted by maybe Ben Cooley on 2000/01/17 12:55:23
I'm trying to get the pliant.c base pliant system to work in MSVC as I have to
use C to get the COM access stuff into pliant (which I think is the nicest way
to provide cross process functionality in Windows). The COM system is
certainly programmable in Pliant, but easier in C (at least right now).
However, I'll explore programming it Pliant, as I think it'd be nice to have
as much as possible in Pliant, and not in C.
Just a question.. have you considered an import_cheader meta function which
would import external C symbols, macros, etc. into pliant. That would really
be a boon when interfacing with C operating system files. I can't imagine
having to rewrite in pliant every single C header file for windows.. I believe
there are literally several hundred of them.
|Message posted by maybe Ben Cooley on 2000/01/17 13:32:26
|Apparently the lockup is a call to an invalid function in
FUNCTION Void Expression_postcompile_rewrite(struct Expression *e)
when compiling '/language/debug/record.pli (internal) 28 7' during the
compilation of the standard environment dump file at debug level 2.
Apparently this is a return statement.
I don't know where 'record.pli' is included in the build tree for the
main system, but I suspect it's pretty early, so there must be something
Currently I'm using the non _REGISTER_ version of the WATCOM calling
convention macro defines.. which I believe is about as safe as can be.
I'm assuming that esi and edi and ebp are being saved by pliant, I don't
know about ebx,ecx, and edx.. Does watcom require these be saved... I
don't recall MSVC ever pushing these in its stack frame setup code.
Also.. MSVC's lint is much stricter than what you're using.. as I get
a whole mess of 'unused variables', 'signed unsigned conversion', etc.
as warning messages. I turn these off right now, but it might pay to
look at them as possible sources of bugs in certain situations..
|Message posted by maybe Hubert Tonneau on 2000/01/18 00:01:36
|What I have added in release 31 is the ability to use Pliant in a C
or C++ program (using C programs in Pliant ones was already available,
see at end for extra details), let's say compiled using VC++, without
recompiling Pliant executable and DLL.
In order to achieve this, the Pliant DLL is exporting a single function
named 'pliant', and this function is using WINAPI calling convension,
so you can call it from a program compiled with any compiler.
Now a way to load, then call Pliant DLL is demonstrated in
This sample is written in Pliant, but you could write it in C: it
loads Pliant DLL (performed by the 'pliant_startup' function prototype
declaration), then builds the five arguments (with C like encoding, not
Pliant encoding) that are required to pass to 'pliant' function in the DLL
and finally call it.
The arguments are:
- the number of arguments (same as argc in the main)
- the arguments (same as argv in main, with the same encoding)
- the environment (not used under Win32 because the environment
can be obtained at any time through a call to a Win32 function.
Under Unix, it's also using the classical C encoding)
- the debugging level you want to use in Pliant (0 or 1 if you
load pliant-debug0.dll or pliant-debug0.so and 2 or more if you
load pliant-debug2.dll or pliant-debug2.so)
- a '\0' terminated string specifying Pliant path (typicaly
/pliant/ under Linux and c:/pliant/ under Win32)
The arguments you can pass in the second parameter are the same you can pass
if you call Pliant executable.
What you will have to do is pass a long first argument that will look
like the following ('\0' termined string):
memory_base_address 1792 precompile /pliant/language/dump/embedded.dump reset module /pliant/install/precompile.pli
What it says is that Pliant must use memory area starting from 1792MB,
then try to load /pliant/language/dump/embedded.dump file, and if none
is available then precompile the PDEE and put it in so that it can
fast start the next time (you have understood: the first time, starting
Pliant will be very slow because it will precompile the PDEE).
It is important to specify the memory area because the .dump file have
no relocation capabilities so all this will work provided:
- the Pliant DLL loads at the same address (this can be a problem so
the best is to load it at the very first line of you C main function)
- the specifyed areas are available so you must adjust 'memory_base_address'
so that the C part of your application never use to parts Pliant
will need .
Now, the extra aguments can specify whatever you want that will enable both
parts of application to work together. It will generaly provide the name of
a module to load (the interface module) and a call the a glue function in
this module with set of addresses as arguments (the addresses of the C
functions to use from Pliant; remind that you must use WINAPI prototype so
that both compilers agree on the calling convension). It can also give the
address of functions pointers in your C code that Pliant will fill with
addresses of some of it's functions, so at the end you've got a tight link.
Returning a the end is not supported yet, so at the moment, you have
to create a thread in your C code, then load Pliant DLL and keep it running
At a later point, when the 'pliant' function returns, it will simply
free all allocated memory pages, so that Pliant dynamicaly and cleanly
unloads itself from the calling process memory space, and that you can
launch it again at a later point.
A right now available alternative is not to create a new thread, but call
back a C function from Pliant.
On the other hand, if you simply want a Pliant application to use
some DLLs written in C (maybe compiled using VC++, then again, you don't
need to compile Pliant engine using VC++; you only need to specify WINAPI
in your C functions prototype, and use 'external' keyword in Pliant: it's
completely strait forward, and it's the recommended way because it will work
perfectly with no heavy glue code.
|Message posted by maybe Hubert Tonneau on 2000/01/18 13:31:16
|This is the last stage I plan in order to allow Pliant to be mixed
nicely with other applications:
1 Instead of building a DLL using gcc (or watcom), I will simply
build an assembly listing using Linux gcc (even if the target
plateform if Win32)
2 I will parse the assembly listing in order to turn it to a set
of very simple instructions for the Pliant loader:
instruction 1: reserve an area of memory (address, size)
(only for Win32)
instruction 2: commit an area of memory (address, size)
instruction 3: fill an area of memory with bytes red from the file
instruction 4: set a pointer with address of given external function
(dllname, functioname, pointer_address)
(only for Win32)
instruction 5: 'pliant' startup function address specification (address)
In short, that's the utltra simple specifications for a DLL loader
... with no relocation capabilities.
As a result, the Pliant main DLL will be turned to a binary file
that follows these specifications, and I'll write a loader for it
in the pliant loader (the current small executable) and another
one in a DLL (the DLL you will load when you want to load Pliant
from another application).
As a result, we will be granted that Pliant C part is always loaded
at a fixed address, so we'll have the ability to freely mix with
any other application ... without facing the much harder relocation