Re: Writing small .COM executables

On Sun, 16 Mar 2008 07:59:38 +0000, Alex Buell <spamtrap@xxxxxxxxxx>
wrote:

On Sat, 15 Mar 2008 22:02:10 GMT, I waved a wand and this message
magically appears in front of Frank Kotler:

I've just noticed that when I use buffers in my COM executables,
they take up space, leading to wasted space when stored. From what I
remember years ago that there were ways of reducing the footprint
the executables takes up on storage media by allocating from
elsewhere. How?

Well... assuming we're talking about "dos .com" and not Common Object
Module "COM" (thanks a pantload, Microsoft!), and assuming we're
talking about Nasm, put your uninitialized data in "section .bss",
and use "resb/w/d/q/t/o". Fasm uses "rb", etc. but I don't know how
to tell it "section .bss" - just put it at the end, I guess - that's
all Nasm does with it. (there are no "segments" in a .com file, it's
all just laid out flat - Nasm puts ".data" after ".text" and ".bss"
at the end - it doesn't really "exist", Nasm just defines labels
in .bss).

Ah, thanks I know what the error I've made - I did put all my
uninitialised data in the .bss section, but forgotten all about the
resb/d/q/t/o - I've been using db/w... Excellent, I'll save a lot of
space!
--

Just remember that unless you do something to move it, the stack is at
the top of your COM segment by default, and grows down toward that
area you are using for BSS data. If you have a large COM app (code
plus all data) and/or large stack needs due to recursion or whatever,
you should either move your stack or put some of your data in its own
segment above that. It can actually be a big help to move large data
buffers and arrays to their own segments, becuse then you can index
them starting at offset 0 in their segments. So the index becomes the
pointer without needing a table offset added into every access.

Best regards,


Bob Masta

DAQARTA v3.50
Data AcQuisition And Real-Time Analysis
www.daqarta.com
Scope, Spectrum, Spectrogram, FREE Signal Generator
Science with your sound card!

.

Relevant Pages

  • Re: where do the automatic variables go ?
    ... and bss segments etc...but there is notthing like stack and heap ... automatic objects are placed in some kind of "stack ... like" memory (which under most implementations happens to be an actual ... objects on a stack is also perfectly conforming. ...
    (comp.lang.c)
  • Re: Pascal Calling Convention
    ... One problem with segments is that you need twice as many address ... Most RISC machines I've seen have call/ret, but they are not stack ... Ret jumps based on the content of a register. ... if you are talking about some other target, ...
    (comp.lang.ada)
  • Re: Pascal Calling Convention
    ... the special SS stack segment register. ... simply keeping separate code and data segments. ... It does on most architectures. ... refer to a "hardware stack", which makes no sense to me. ...
    (comp.lang.ada)
  • Re: where do the automatic variables go ?
    ... and bss segments etc...but there is notthing like stack and heap ... Stack variables are implied by the compiler (the compiler generates code ... int foo ...
    (comp.os.linux.misc)
  • Re: executable data segments?
    ... >>everything, stack, heap, data, are executable. ... >>safer to have executable only on code segments to protect against ... Most of the core Solaris binaries are linked with it -- for example: ... % sleep 10 & ...
    (comp.unix.solaris)