1. C_FUNC in DOS
Is there a way to use something like define_c_func(a,s1,s1,i2) and
c_func(i,s) in DOS. My problem is that I need to know how to pass
parameters in eu to a function and use them in side the C function.
I understand how to do this in another languges by getting the parmeters
off the stack. But how can I do this in eu in DOS.
I would thankfull for any help
2. Re: C_FUNC in DOS
At 05:25 p.m. 04-01-99 , you wrote:
>Is there a way to use something like define_c_func(a,s1,s1,i2) and
> c_func(i,s) in DOS. My problem is that I need to know how to pass
> parameters in eu to a function and use them in side the C function.
> I understand how to do this in another languges by getting the parmeters
> off the stack. But how can I do this in eu in DOS.
What C function do you want to call in DOS ?!?
Euphoria is interpreted, so you can't link OBJ's!
Regards,
Daniel Berstein
daber at pair.com
3. Re: C_FUNC in DOS
I can convert a c function obj file to a hex sequence just as is
done in assembler, and then call that hex sequence but I have to
be able to pass the parameters. Thank You Bernie Ryan
4. Re: C_FUNC in DOS
At 11:19 a.m. 05-01-99 , you wrote:
>I can convert a c function obj file to a hex sequence just as is
>done in assembler, and then call that hex sequence but I have to
>be able to pass the parameters. Thank You Bernie Ryan
But your hex sequence would contain not just machine code, but
also linker specific data. I'm i right? I hope I'm wrong, would be
very interesting.
Regards,
Daniel Berstein
daber at pair.com
5. Re: C_FUNC in DOS
Bernie Ryan writes:
> I can convert a c function obj file to a hex sequence just as is
> done in assembler, and then call that hex sequence but I have to
> be able to pass the parameters.
In DOS32, you can create an intermediate machine-code routine
that gets control from Euphoria's call(addr). This intermediate
routine will have to set up the necessary parameters in the
way that the C routine expects them. It might have to load
values into specific registers, or push them on the stack -
whatever the C routine expects. Your Euphoria code can poke the
parameter values into memory, perhaps into the
intermediate routine itself. The intermediate routine must
return with a RET #C3 instruction, and must save/restore
any registers that might be modified.
The other alternative is to directly modify the machine code
of the C routine itself, to pick up parameters from memory
and return with a RET.
The calling convention can vary from one DOS C
compiler to another. Sometimes parameters are
passed in registers, and sometimes on the stack.
Make sure you are generating 32-bit code from
your C compiler.
In WIN32, calling C routines is much easier.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
6. Re: C_FUNC in DOS
Thank You Robert for your help
I have some more questions.
If I allocate memory at the begining of a program does that memory stay
stay in scope throught out the whole program ?
When one eu function calls an eu function does it use the stack?
Is there a way to locate the stack, and push something on the stack.
and recover it without disturbing eu ?
How does C_FUNC and C_proc work in win32lib ?
I understand that it uses the DLL's but this same thing will work
if define_c_function and define_c_proc were written to work on any hex sequence
of code that was poked into memory as long as it was setup in the format of a
dll.
Thank You again
7. Re: C_FUNC in DOS
Robert Craig wrote:
>In WIN32, calling C routines is much easier.
Why not add support for using .OBJ files ?
As a counterpart to the Win32-call_func () one that works with .OBJ files
rather than .DLL files.
There are a number of advantages:
You could strip down lots of these 'machine_function's you have currently
built-in. This way we could choose which parts of code to be loaded at
run-time. Loading the object file, etc. is done by wrappers just like now.
Only they dont call the built-in routines machine_func () and machine_proc
(), now they either call a DLL (win32) or an .OBJ (dos32).
I mean, take the whole built-in graphics engine, my binded Botmatch contains
both the Neil engine, the Watcom graphics engine, etc.
Also, it might be better, if more of the includes are pure Euphoria. It
saves a lot of huge
watcom libraries that are currently loaded, and it is better maintainable.
For example things like dir (). There are already counterparts that also
read the LONG_NAME attribute of directories and files, in pure Euphoria. Why
not use such a routine rather than the built-in one ? (which does not give
the long-filename on DOS32)
Im personally also in favor of the naming convention to use EXD as
the extension of DOS32 *only* files. And why not try to keep things as
platform independent as they can be. For example, a real log window gets the
'puts (1, ... )' and an input (0) is done in the log window. (it only shows
up when we actually puts or input something). And where is the counterpart
of the graphics library with Win32 ? It is possible to have a 100%
compatible counterpart. Or take 'message_dialog', why not have a DOS32
counterpart ? Not much effort, but great for portability.
Maybe a special routine that works on both platforms and instead of action,
rather designed towards a certain goal, is better: maybe something called
'log_output' and
'log_input', together with 'gui_ask' and 'gui_tell' ?
And yes, we could write all this ourselves, but specific routines like sound
() and wildcard-matching are also available. And the for the above named
routines its much more logical to have those standard with the program, than
with specific ones like that.
Also I suggest a small 'compiler-switch'.
Just a:
with 1
-- This is read by the interpreter
wihout 1
-- This is not
with 0
-- This is not
without 0
-- This is read by the interpreter
'trace' etc. are just special cases, and the include file default.e is
*always* included. (it should contain things like: the platform () function,
and other maybe certain other small things)
This way, we could say:
with platform() = WIN32
with platform() = DOS32
Saves speed, and often we have total different routines, or want to
overwrite built-in routines just in ONE of the two currently supported
operating systems. (and yes, I know the trick around that)
Lastly, I hope that you can find a way to determine when 'inlining' will be
faster. Off course only local routines should be inlined. (you could just
move this part to the shrouder/binder to avoid name-conflicts with local
declared routines, it would solve lots of problems and increase speed)
Ralf N.
nieuwen at xs4all.nl
ralf_n at email.com
8. Re: C_FUNC in DOS
Thanks Ralf I agree with you.
This would free us from depending on any specific
operating system. It could even lead to a Eu operating system.
9. Re: C_FUNC in DOS
Ralf writes:
> Why not add support for using .OBJ files ?
> As a counterpart to the Win32-call_func () one that works with
> .OBJ files rather than .DLL files.
That would be a great feature, but I don't think there's
any practical way to implement it. Dynamic linking is supported by
the WIN32 O/S but not by DOS.
A couple of years ago a user provided me with a demo program
that would:
- open a .OBJ file
- read in the machine code for a C routine
- call() the machine code
It looked pretty good. You could modify and recompile the
C function and then run the Euphoria demo program.
However:
- the .OBJ had to be created by a specific C compiler (GNU I think)
- a special compile option had to be supplied to that compiler
- parameters could not be passed
- the routine could not call any other routines, not even
library routines
- the routine could not reference any global C variables
Given these restrictions, and the difficulty in overcoming some of them,
I've never proceeded with DOS "DLL" support. Maybe a "third-party"
could try to improve on the demo above, for some specific C compiler.
I don't think this necessarily requires any support from ex.exe
Bernie Ryan writes:
> If I allocate memory at the begining of a program does that
> memory stay in scope throughout the whole program ?
Yes, you can use it until you free() it, or your
program terminates.
> When one eu function calls an eu function does it use the stack?
No. It uses an internal Euphoria "call-stack" in memory
which has nothing to do with the machine stack.
> Is there a way to locate the stack, and push something on the stack.
> and recover it without disturbing eu ?
You have to use PUSH and POP machine instructions in a section
of machine code.
> How does C_FUNC and C_proc work in win32lib ?
> I understand that it uses the DLL's but this same thing will work
> if define_c_function and define_c_proc were written to work on
> any hex sequence of code that was poked into memory as long
> as it was setup in the format of a dll.
define_c_func() and define_c_proc() call an O/S routine that returns
the machine address of the C routine. This address is
saved in a table, and a small integer value is returned to you.
Later, when you call c_func() or c_proc(), passing the small integer
value, Euphoria indexes into the table, gets the address,
the number and type of parameters etc., and makes the call.
There's a standard C calling convention on WIN32 for making such
calls, that requires the arguments to be pushed onto the machine
stack (the last arg is pushed first as I recall).
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
