[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] m68000 version of Zorro's LDG codec
Hello Zorro
Le 27/09/12 21:28, OL a écrit :
You can send memory allocated by malloc() to the codec without problem
Yesterday evening, I looked at the code of the LDG library.
Olivier and MiRKO, you are right and I was wrong.
You can send a memory pointer allocated with malloc() to the called
LDG because from the OS view, the LDG and the client are the same
process.
Yes if the lib is not shared.
I made the mistake of believing that the processes were differents.
So Mirko, you were right to remove men.ldg from the zview code!
Another problem: Can you use the MiNTlib functions inside a LDG?
In the case of a shareable LDG, The MiNtlib functions cannot be used.
http://tinyurl.com/cq6qycz
http://tinyurl.com/bu9hgf3
It's a pity because if a shared library is not... shareable, there is
just no interest.
Yes and no, I use ldg as plugin that I can load and unload when I want,
I can change it without looking in application
(for example for my first bench on coldfire (some years ago!)) I just
compil ldg for test so I was able to have native bench
without need compil Kronos itself (this was a little bit more difficult!)
Now, there are 4 solutions to make a shareable LDG:
- Do not use the MiNTlib functions inside the LDG.
Yes
- The Mirko idea: provides callbacks to client's MiNTlib.
This is an idea but work only for GCC, can't be used by other compiler
(you perhaps not know but EB Model use LDG
in it and it is in GFA!)
- Rework the MiNTlib( the hard way).
Forget Mintlib there is too much work! It should be better to adapt
newlib (http://sourceware.org/newlib/) it is fully reentrant I think
- Code the real shared libraries support directly in the Kernel( the
very hard way).
Yes probably the best, but not universal (can't work on Magic or TOS),
but in fact it could be simply an real ldg sharable!
MirKo what do you think of this for your problem? with it we could solve
the problem of FPU format and parameter transfer, we could in fact
create 2 or 3 libc.ldg for each format the choice could be simply done
in the client lib. Yes I think this could be an elegant way to solve the
problem but we need a reentrant libc.
MirKo, Olivier, do you agree?
Globally yes.
In the case of a non-shareable LDG:
I can't remember why but in the past, I met strange behavior and
instabilities when I used MiNTLib functions.
Me too, you are right , because I remember now I compil with PureC
without problem but not with GCC at this date I was working on MagicMac!
and as describe the problem of Wonck this is his problem and now to fix
it we use sharelib patch, but I remember too that Arnaud said me not so
far that it was only for share memory, perhaps he forgot as me this story
After reading an old discussion( for the french speaking people:
http://tinyurl.com/d9v4dyu ) , it seem that Olivier, Arnaud and me
agreed: it's better to avoid using the MiNTlib functions inside a LDG.
This is so old! My memory start to be deffective!
But it was 8 years ago. Maybe now, is it safe to use the MiNTLib
inside a non-shareable LDG?
It should and it work under Mint (I use like this jpeg.ldg 68000 without
known problem but it doesn't work under Magic (why?) but work with
libshare).
Olivier
--
Zorro