delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/08/22/19:47:57

Sender: nate AT cartsys DOT com
Message-ID: <35DF1418.402230C2@cartsys.com>
Date: Sat, 22 Aug 1998 11:55:20 -0700
From: Nate Eldredge <nate AT cartsys DOT com>
MIME-Version: 1.0
To: Endlisnis <s257m AT unb DOT ca>
CC: djgpp AT delorie DOT com
Subject: Re: Inline asm
References: <199808010337 DOT EAA08924 AT sable DOT ox DOT ac DOT uk> <35C29036 DOT ADF11F19 AT access DOT net DOT au> <35D253DA DOT B04B8D98 AT unb DOT ca>

Endlisnis wrote:
> 
> Donald McComb wrote:
> 
> > Ahhh... But I thought memcopy copied the memory in byte sized chunks,
> > rather than longs, and thus wouldn't be quite as fast as it could be.  I
> > hope you're right... that solution is far more appealling than inline
> > asm :)
> 
>     No, memcpy (no 'o') copy's 4-byte chunks (but also works with blocks not
> divisible by 4).  There is a function memmove that copies 1 byte at a time
> in case the regions overlap, but it is (essentially) 4 times slower.

You are thinking of `memmove', but it also uses 4-byte transfers. 
(Think about it-- 1 byte at a time wouldn't help the case of overlapping
areas.)  What it does is copy backwards if necessary.  I think the
reason it's slower (if indeed it is) is because it's written in C rather
than assembly (this is from memory and may be totally wrong).  AFAIK,
this will change with 2.02
-- 

Nate Eldredge
nate AT cartsys DOT com


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019