Re: Help with Enter and Leave Instructions


T.M. Sommers wrote:
>
> >> for Memory Accesses,
> >
> > Right. The int 80h interface only gives us "chunks" of memory. We need
> > to manage the chunks ourselves. The "normal" way to do this would be
> > with the C library's "malloc".
>
> The only standard way to do it is via malloc. Do anything else
> and you rely on undocumented, nonstandard, implementation details.

Uh, SBRK/BRK is a standard, documented system call. You can also use
the memory-mapped file scheme to allocate memory in a very standardized
scheme (e.g., many C stdlib malloc implementations under Linux use this
scheme, it's also the scheme I use for the mem.alloc function in the
HLA standard library).


>
> > We can write our own "malloc", but I
> > suspect they'll conflict if we try to do both.
>
> It would be a problem only if you used your own memory allocation
> alongside malloc in the same program (not counting the
> above-mentioned problem of being nonstandard). There are
> replacement mallocs around, and it is no problem using them, as
> long as you use only them.

Actually, it's not a problem if you use the memory-mapped file scheme.
You may get some extra memory fragmentation that you wouldn't have
otherwise gotten, but if you're calling C's malloc and HLA's malloc
routines in the same program, everything will work fine. The OS manages
the memory properly for you.

>
> > This could be a problem,
> > since using any library - Xlib, say - is likely to pull in libc also. So
> > we may be "stuck" with C's malloc, if we use Xlib. (shouldn't be a
> > problem with "libASM")
>
> Yes, it could be a problem if any library function you call calls
> malloc.

See above.

>
> >> for Debug support,
> >
> > I'm not sure what you have in mind here. ELF has two ways to put
> > symbolic debug info into the executable ("stabs" and "dwarf"). Gdb and
> > ald use "stabs"...
>
> It is more that Linux uses stabs. FreeBSD uses dwarf, but both
> Linux and FreeBSD use the GNU toolchain, which supports both.

I suspect that Rene is discussing hooks into the OS. As he doesn't know
anything about C, I suspect he didn't recognize the word "signals" in
the Linux documentation and realize that this is how you hook into the
system for "debugging support".

>
> > For "serious work", I'd be tempted to use
> > libraries, but I'd still have an inclination to keep everything "in
> > house". A library written in asm - even if by somebody else - would be
> > preferable to a library written in C, for example.
>
> I really don't understand the objection to using C libraries. I
> mean, they are libraries; who cares what language they are
> written in? The OS is writtin mostly in C, and no one objects to
> calling it.

This is the most amusing part I've seen in the Win32 Asm world --
people griping about a few nanoseconds overhead here and there when,
ultimately, they wind up calling C code in all its glory when they
enter the OS anyway.

And just to finish the story, you do *not* write GUI apps under Linux
by simply making XWindows calls. You pick a nice environment, like
GNOME or KDE, and you like (dynamically, I believe) with their
libraries. Writing XWindows code is like doing windows programs by
calling nothing but the drawing routines. No Widgets. Nothing. If you
want to do GUI apps, pick a Window manager and write code for that.
And the cool thing is, if your code is made reasonably portable, the
same program will run under BSD and any other OS running that same
Window manager (the trick, of course, is that you have to isolate
system calls, i.e., int80h, because those calls are *not* the same
between OSes).
Cheers,
Randy Hyde

.

Relevant Pages

  • Re: Differences between C++ and Java
    ... > are *implementation* defined and the standard also specifies the ... > "In Java, garbage collection of unreferenced objects is automatic. ... > C++, you manually manage memory. ... > provide third party libraries that work just as well, ...
    (comp.lang.java.programmer)
  • Re: close fd while select/poll/epoll
    ... out of memory other than malloc returning NULL. ... POSIX *cannot* make this illegal. ... my proposal becomes part of the standard. ...
    (comp.os.linux.development.system)
  • Re: malloc under linux
    ... It means what it says, i.e., even if malloc returns a non-null ... memory might not actually be allocated. ... Standard even when some other process is killed and sufficient memory is ... I can't see how the Standard does not permit lazy allocation, ...
    (comp.lang.c)
  • Re: [9fans] quantity vs. quality
    ... >>> Another example is using emalloc in libraries. ... > Well I wonder what people typically do when they can't malloc anymore ... > memory but need more... ...
    (comp.os.plan9)
  • Re: calloc/free: a preplexing observation
    ... standard does not prohibit memory overcommitment. ... > that isn't necessarily properly aligned, malloc() has to arrange to ...
    (comp.lang.c)