[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] mshort support
Miro Kropacek wrote:
The main reason is 16bit API everywhere you look -- not only TOS API
itself but also XDD/XFS/XIF, XHDI etc APIs. So the solution would be to
wrap syscalls (16bit -> 32bit wrapper)
My very personal opinion:
I would prefer to get rid of mlong and keep only mshort.
The manipulation of 32-bit integers is slower on 68000 than 16-bit ones. I
don't want artificially slow programs on my ST. I don't want to have to call
a slow function to compute 3*5. And I don't care about Unix software, I will
never use them on ST.
On ColdFire, it is the opposite. The instructions behave optimally on
aligned 32-bit values, manipulation of 16-bit values usually requires more
instructions. I don't want a 16-bit kernel on my future ACP computer.
Now back to the reality.
We need 32-bit support because most software from the outside world require
32-bit integers. Including the MiNTLib (based on glibc). And as you said,
everything in our OS use 16-bit integers. We will probably have to live with
that.
Btw Vincent, is there any way how to separate generation of mshort for
libgcc and libstdc++ (and the others) ? Because as you have already
pointed out, we need mshort for -lgcc link input but I see generation of
all the others for -mshort as complete waste of (mine and CPU) time...
I don't know. We will have to find some way.
I think the best thing to do is to enable all the potentially useful
multilibs in gcc, in order it can recognize the multilib options and their
associated directories.
Then disable the generation of useless mshort libraries, for each library.
The GCC makefiles have a nice feature, they can compile automatically the
GCC libraries for all the multilibs supported by the compiler. It is the
same for Newlib. But this feature is not automatically supported by
autoconf/automake.
Note about Windows: Microsoft has updated the OS API when switching from
16-bit to 32-bit. And again when switching to 64-bit.
We could imagine doing the same: write a new TOS with a full 32-bit API,
with something more clever than the traps, linea... certainly a huge task,
without big benefits.
--
Vincent Rivière