[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Library files not in their proper distribution?
On Sun, Apr 12, 1998 at 08:26:54PM -0400, Katherine L Ellis wrote:
> How about including portlib into the mintlibs where they belong?
> I thought the aim of portlib was a temporary evolution of the standard
> mintlibs.
The portlib has a different copying policy than the MiNTLib. And
one shouldn't migrate the sources into another library without
asking the author (Kay Roemer).
I would personally prefer to leave the portlib alone in order to avoid
confusion about the copyright stuff. Or even better: Put the
MiNTLib under the GPL. If the portlib was simply integrated into the
MiNTLib people just won't care about the copyright stuff. (In fact
the doprnt() function is for example BSD-copyright. Have you
ever seen the BSD copyright notice in shareware programs that
are linked with the MiNTLib?)
A propos Kay Roemer. He doesn't have an Atari anymore and
he has given up support for both the portlib and MiNTNet.
What do you out there think about moving the socket functionality
into the kernel (where it actually belongs)?
> Also question, How come a lot of soft IF compiled with 32bit interger
^^ Sorry, what's that?
> don't work? why is mshort needed at all to make a soft to work? I
> thought it was to be more effective. Any answer about that?
I think that 16-bit integers are simply stone-age, completely
obsolete. It causes a lot of problems, executables get bigger(!)
and you will rarely find portable software that is really 16-bit
clean (nowadays that 64-bits are really coming up).
Why mshort at all? An example. Take a definition like
struct timezone {
int tz_minuteswest;
int tz_dsttime;
};
When using 16-bit integers this structure is 4 bytes big,
with 32-bit integers it has 8 bytes. This isn't a problem
as long as you use this structure only internally inside
your program. But if you pass a pointer to the structure
(i.e. its address) to another program (for example the kernel)
to read/write its contents the two programs have to agree
about its size. If you pass the pointer to a library function
you have to make certain that your program and the library
have the same notion about its size, too.
As far as efficiency concerned, the m68k family of processors
has 32-bit registers. Using 16-bit values actually costs
performance because the compiler has to insert additional
assembler instructions to mask out the bits that aren't
used. When you also consider that for signed variables
the first (i.e. highest bit for Motorola) holds the sign
information things get even clearer: This "sign-bit" has to
be bit #0 for long integers and bit #16 for short ones.
A lot of hubba-bubba, and actually no advantages.
Ciao
Guido
P.S.: If you simply want your compiler always to link against
the portlib (without giving it the -lport option) just make sure
that your specs file (/usr/local/lib/gcc-lib/m68k-mint/<version>/specs)
contains two lines like:
*lib:
-lport -lc
That's it. And maybe the function prototypes for the routines
provided in the portlib should go into the proper header files.
--
http://stud.uni-sb.de/~gufl0000
mailto:gufl0000@stud.uni-sb.de