[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] mshort support
Vincent Rivière wrote:
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.
Exactly how I feel about it.
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.
Sensible.
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.
TOS only uses trap 1,2,13 & 14
Create new traps for complete 32 bit API's.
trap 3 for GEMDOS
trap 4 for AES/VDI
trap 11 for BIOS
trap 12 for Xbios
Exercise in Emutos. Programs have to be ported anyhow.
What is good about 16 bit integers?
90 % of integral numbers used in programs are small enough
to fit in 16 bits. And please, do not confuse numbers with
pointers. (Pure C is a 32bit compiler)
32 bit ints (let alone 64 bit) are a immense waste of space.
Be aware! Not only in memory, which is cheap nowadays, but
also in all the places where binaries are kept and transfered
back and forth millions of times.
Useless zero bits waste bandwith all over the world.
--
Groeten; Regards.
Henk Robbers. http://members.chello.nl/h.robbers
Interactive disassembler: TT-Digger; http://digger.atari.org
A Home Cooked C compiler: AHCC; http://ahcc.atari.org