home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.asm.x86      Ahh, the lost art of x86 assembly      4,675 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 3,604 of 4,675   
   Rick C. Hodgin to sdn4...@nospicedham.gmail.com   
   Re: EXE program stack setup questions   
   17 Oct 18 11:18:59   
   
   From: rick.c.hodgin@gmail.com   
      
   On Wednesday, October 17, 2018 at 1:57:25 PM UTC-4, sdn4...@nosp   
   cedham.gmail.com wrote:   
   > My understanding of how a COM program really works (in real life)   
   > is that DOS reserves ALL 640K memory and all segments are supposed   
   > to point to the code segment (64K or less). When you reallocate it   
   > is up to you to define the SS. If you are mixing your COM program with   
   > other code not in ASM then as Emilly Latella would say (never mind),   
   > might as well use an EXE. I routinely use all available ram with tiny COM   
   > programs and have never had a problem, but for COM programs NASM   
   > doesn't assume anything, you must tell it.   
      
   My recollection is that TINY model .EXE, and all .COM files,   
   received the full memory initially allocated to them once they   
   start.  You had to explicitly do a resize, and then re-allocate   
   memory as needed to obtain known blocks of memory that weren't   
   akin to guesswork as to where you're writing to, what you're   
   over-writing, etc.   
      
   Except for very niche apps, I can't see a reason to explicitly   
   use a .COM model any longer.  Memory's cheap, and you can do   
   in most C-like languages 95% of what you can do in assembly,   
   and do so more generically, portably, and more clearly.  For   
   those 5% cases where you truly do need x86 assembly, it's nice   
   to have those abilities ... but I would advise anyone seeking   
   to do lots of assembly work today to reconsider the goals of   
   the app.  Years roll by, and other platforms become popular.   
   The Nn% savings in performance you have by going to assembly   
   are lost by not having the ability to translate to the other   
   architectures.   
      
   But when it's needed, it's definitely to be used.  I have had   
   to use even 64-bit AMD64 assembly for writing a custom dispatch   
   algorithm to call DLLs loaded at runtime that are unknown at   
   compile-time, but are given through a type of parsing at run-   
   time.  The AMD64 dispatch model calling convention uses an un-   
   usual format for how its parameters are passed, and to setup   
   the stack in that way required some custom assembly.   
      
   --   
   Rick C. Hodgin   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca