[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] MiNT lib 55
Hi,
On Fri, May 12, 2000 at 05:45:36PM +0200, Konrad M. Kokoszkiewicz wrote:
> Hi,
>
> I have installed the MiNT Lib PL 55, and have a bit mixed feelings. Well,
> the PL 55 is undoubtfully more worked out than previous versions were, at
> the other hand many programs don't compile anymore (like the original
> Stephen Usher's init package: 8 out of 17 programs compile, and among
> these, which don't, is init itself, syslogd and login, so three most
> important ones); at the third hand :-) I can accept that last as long as
> the new lib will be better for porting new software... anyways, several
> questions are left:
>
> 1) The comment in stdio.h regarding the binary mode for streams is a
> little bit unclear, when about the stdin, stdout, and stderr.
> Are these binary now by default, so that code like
> stdin->_flag |= _IOBIN can be just removed?
That wouldn't even compile because FILE has no member "_flag". The glue
code (to which you refer maybe) is only useful for compiled code (like
code you find in older libraries). In brief: Old standard stdio
implementations (like the old MiNTLib) generally define the standard
streams like this:
extern FILE* _iob[];
#define stdin _iob[0]
#define stdout _iob[1]
#define stderr _iob[2]
In glue.c the MiNTLib still defines the array _iob in a way that is
mostly (amap) compatible to the old implementation. If you have old code
that references _iob (in your C sources this will be hidden in the macro
stdin, stdout, or stderr) the library "casts" these references to pointers
to FILE. Each FILE in the new stdio model has a magic number in the first
bytes which allows to distinguish between "real" FILEs and
"glued" FILEs. If a glued FILE* is referenced, almost all calls translate
their glued FILE* argument to a new (real) FILE*. The implementation in
the MiNTLib compared to the GNU libc has the advantage that it not only
looks nice but also works. ;-)
See README.stdio for a better understanding. You will also learn
something about the many benefits of the new stdio model. One of them is
that the new MiNTLib allows you to open as many FILE streams as you like
(until the OS runs out of descriptors for regular files or you run out of
memory if you also use the "virtual" streams of the new MiNTLib like
memstreams or obstreams).
To answer your question: The old code
file->_flags |= _IOBIN;
file->_flags &= ~_IOBIN;
now translates to
file->__mode.__binary = 1;
file->__mode.__binary = 0;
For alternative methods see <bits/stdio_mint.h>.
> 2) Where the macro S_IFBLK is defined (in PL 49 it was)?
See reply to Q-Funk. Add -D_BSD_SOURCE to your CFLAGS and then read
NOTES. ;-)
These new problems will also arise on recent Linux installations and it is
therefore quite likely that the real problems (which lie in the sources of
the software, not in the libc) will be fixed quickly. If you have
problems compiling software with the new MiNTLib, try to get the Linux
patches and apply them. This will fix most problems with the MiNTLib,
too.
> 3) Why a "program" like:
>
> #include <mintbind.h>
>
> int
> main()
> {
> Cconws("Dupa blada\r\n");
> return 0;
> }
Become an ld wizard! ;-)
I can link that into a file of less than 400 bytes. It would be less
than 20 Bytes without the header and the relocation info.
> which does not contain a single library reference, has exactly 39
Sure it contains library references: _start, __main, _environ, ...
> kilobytes after linking (and stripping symbols)? Isn't that a little
> exaggeration? Why the binary contains a message like "This program
> require(s) a FPU!", while I didn't specify -m68881 in compiler options?
Fixed. This was a bug in the startup code which can only be found in the
precompiled Sparemint version of the library (i. e. not in the original
sources). Please update to 0.55.3 which uses a correct method for FPU
detection (alternatively set the cookie "_FPU" to 0).
> Why there's a text "assertion failed" compiled in, when I didn't use
> assert()? Upto PL 49 it was quite difficult to make a program, which
> would be under 10k in final binary, now this is 4 times more. Are
> memory expansions (for Falcon) 4 times cheaper today?
I'm aware of that size problem and if you study the old ChangeLog.0 file
you will also see that I tried my best to keep the increase in size as
small as possible. The last measure (which took me a lot of time) was to
still offer a libiio.a. Linking with "-liio" should save about 15-20
kBytes.
The reason for that annoying size problem is simple to find and hard to
solve. The startup code contains a lot of library references and drags a
lot of seemingly unused modules into the link. In "normal" applications
this is not such a big problem because you will reference most of it from
your application code as well but in pathological cases like your
three-liner it is a nuisance, that's right.
I have already given a lot of reasons for the larger binaries in a
previous thread. In brief: Old MiNTLib versions had countless bugs which
turned up when I added the test suite to the MiNTLib. The most common
reason for the bugs was that the old code was too simple, ignoring a lot
of special cases or tolerating bugs. I have tried to overcome that either
by adding code for special cases or by updating the sources to newer
versions from other sources which had fewer bugs, more features and which
are mostly bigger.
Another aspect is that the MiNTLib is optimized for speed, not for
size. It's the year 2000 and I think there is no need to debate about
that.
Then, in the last couple of months there have been a lot of improvements
been done to the kernel. Have a look at files like stat.c. It contains
four fully-featured versions of stat(). If I wouldn't have to emulate
every second call for dumb systems like Magic the MiNTLib would be a lot
smaller.
Last but not least, I try to prepare the MiNTLib for being used as a
shared library and also for multi-threaded applications. Both goals
require often a lot more strictness (and a lot more code). Run nm on the
libc of a modern system like Linux. You will see that even simple stdio
calls reference half of the portable thread library. The MiNTLib already
contains a lot of entry points for such future extensions and that costs
bytes, too.
You will agree that an extra 30 or 40 kBytes wouldn't count at all if the
MiNTLib was a shared library. But the MiNTLib won't become a shared
library in just a day and in the meantime you either have to live with the
larger code or you have to stick with an older version. Don't ask for a
bugfix-only version. Bugfixes generally result in bigger code; that's
what I am trying to explain.
> 4) Why a simple program after compiling and linking with "-pg", once run,
> immediately gets killed by the code in bios.c, which protects the
> system against changing an exception vector into private memory? And
> simultaneously cursor stops blinking, what is the normal MiNT reaction
> after the GEMDOS timer vector gets unhooked. Do profiling functions of
> the library use GEMDOS timer? What for, and why (apparently)
> changing something directly, not via Setexc()? And BTW. doesn't MiNT
> have interval timer especially for e.g. profiling?
Profiling worked here after some changes in the code and some changes in
libgcc (not tested with the latest kernel). I will re-check that. If
profiled programs crash again, I'm sorry. I really spent a lot of time to
make it run again.
> Thanks for the info in advance,
You're welcome. I appreciated your comments and of course I basically
agree with you. But the new MiNTLib is already a result of a trade-off
between features/speed and memory requirements. I would have loved to add
a lot more features that had to be dropped because they would have
consumed too much memory in statically linked binaries.
Ciao
Guido
--
http://www.stud.uni-saarland.de/
Send your spam to president@whitehouse.gov and your replies to
mailto:guido at freemint dot de