block move clarification - System.Move()

From: Perry Way (no.delphipro.spam_at_no.spam.earthlink.net)
Date: 11/11/03 

Date: Tue, 11 Nov 2003 09:07:09 -0800

Would someone care to clarify something for someone (me) who doesn't
understand ASM yet?

In System.pas the procedure Move() appears to copy memory one chunk at a
time, with chunks capable of being expressed in 8 bit, 16 bit and 32 bit
chunks. This destroys the concept (I had) that block moves occur in one
block (as it would seem so to the Object Pascal programmer) as it is
apparent by setting breakpoints and examining at runtime that multiple moves
occur until the size passed to the procedure is reached.

I've been working on pooling memory and working out ways to make the memory
fragments appear to be contiguous by way of a class that merely points to
each buffer already in existence. In the course of working out contiguous
issues, I have been under the presumption that block moves occur in one
call, thereby leading me to the belief that the most optimized way to copy
memory is in one big block, rather than accessing the memory byte by byte.
Going byte by byte method is easy to accomplish in terms of making two
buffers contiguous, but as soon as the block size is increased beyond one
byte now we need a miracle.. some way to express the block as one contiguous
block.

I am beginning to think I am wasting my time coding a class to join my
buffers. I am thinking now there is a possible way to accomplish what I
want to by modifying System.Move() and adding some intelligence to it that
will understand when to jump from one buffer to another during the read
process. But I do not know ASM, which is why I am here.

I need clarification. First.. are moves only possible in 8, 16, and 32 bit
chunks in ASM? Second, is there a way to query the input variables of
System.Move() that I don't know about? hehehe. :) The input variables are
declared without types, so what is passed is the address to the first
byte/character, therefore my understanding is there is no way to resolve
what type the buffer is. Ultimately I am sensing that any thoughts about
modifying Move() is wasted time on my behalf because even ASM cannot express
a block move of more than 32 bits.

I'd appreciate any thoughts on this contiguous buffer issue. Perhaps one of
you have worked out a way to make this appear seemless in some fashion.

PW

Relevant Pages

  • Re: Expat problems
    ... > buffer is nul-terminated. ... Not a standard header. ... was read in by "chunks" instead of the whole file into memory. ... I say read in the data in chunks. ...
    (comp.lang.c)
  • Re: Optimal Buffer Size To Read A File
    ... > Is there a Buffer size that is optimial based on the framework or OS that is ... > optimal when working with chunks of data? ... "Optimal" depends on where you draw the line between time and memory. ... converted by the text converter. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Discovering variable types...
    ... >- but I suppose MS expect us to use wrappers ... memory allocations for your variables from disk as well. ... >They most certainly are of fixed size, changing the size of a String ... >>me to keep buffer size and current postion right in the memory block. ...
    (comp.lang.pascal.delphi.misc)
  • Re: Discovering variable types...
    ... >memory it points to is on the heap. ... sequentially reading data, if one is randomly reading records, then a ... >project is what's prompting me to improve disk access. ... from a memory buffer I can do it in about a second. ...
    (comp.lang.pascal.delphi.misc)
  • Re: Multicast Directshow Graph Bridging, COW Rustling, & the Use of Portable Holes in Cartoon Ph
    ... memory to share buffer pools across processes and works pretty well. ... You get two basic Direct Show filters, ... issue each GMF-source a virtual memory alias with COW ...
    (microsoft.public.win32.programmer.directx.video)