> [snip]

> >I remember yours looking a little different then that, maybe I'm thinking
> >of fillchar (later on)... but not to be picky, since dx isn't used,
> >couldn't you use mov dx, ds and mov ds, dx instead of push and pop
> >respectively?

> It takes the same amount of time either way, unless you are in 32bit PM,
> in which case pushing DS actually pushes a doubleword (to keep the
> stack aligned).  Then it would be faster.  Although, I suppose it would
> have been better if I had used dx to store ds (I just wasn't thinking).

> Actually, I don't use either one [very much].  I had one place in Wally
> that uses move, and no places that use fillchar (although I did throw the
> new move() in just in case I use it more often).  As for the lack of ADC,
> I coded them about 1 minute before the post (to test them out).  I'd been
> optimizing code for the 486 lately and so I was stuck in that 'mode' of
> thinking.  To get maximum speed out of a pentium, I would have done some
> different things.  To get absolute maximum speed (for 32bit PM), there
> are some other neat tricks.

> lea ebx,[edi+ecx]
> mov edx,[ebx]
> shr ecx,2
> inc ecx
> rep movsd
> mov [ebx],edx

> works great in 32bit mode, but horribly in 16bit mode.  Linus (of Linux fame)
> has said that using all the registers in an unrolled pseudo loop runs
> fastest on the pentium, but I'd hate to handle the overhead associated
> with saving all the regs and setting that up.  Unless you are moving
> megabytes of memory around (which you shouldn't be), then I don't see
> why anyone would use it (other than Linus :).

> >procedure FillChar (var src, dest; count : word; value : byte); assembler;

> >asm
> >  mov bx, count
> >  mov cx, bx
> >  shr cx, 1
>   ^^^^^^^^^^^^^^this could be a little faster by doing:
>    shr cx,33

> >  mov al, value
> >  mov ah, al

> >  les di, dest
> >  rep stosw

> >  and bx, 1
> >  jz @NoStosB
> >  stosb
> > @NoStosB:
> >end;

> We now resume you to your normally scheduled pascal coding questions.

> Oh, fine.  Now that the world knows, I suppose I have to post it ;)

> procedure move(var Source,Dest; Count:word); assembler;
> asm
>    push    ds
>    les     di,Dest
>    lds     si,Source
>    mov     cx,count
>    mov     bx,cx
>    shr     cx,2
>    db 66h; rep movsw
>    and     bx,3
>    mov     cx,bx
>    rep     movsb
>    pop     ds
> end;

> procedure fillchar(var X; Count:word; Value:byte); assembler;
> asm
>    les     di,X
>    mov     cx,count
>    mov     al,value
>    mov     ah,al
>    mov     bx,ax
>    db 66h; shl ax,16
>    mov     ax,bx
>    mov     bx,cx
>    shr     cx,2
>    db 66h; rep stosw
>    and     bx,3
>    mov     cx,bx
>    rep     stosb
> end;

> This procedure will only increase the speed of fillchar() calls when the
> Count is above 128 or so.  It will also fillchar to pointers faster than
> arrays (since pointers are aligned, and arrays are [usually] not).  I
> just wrote the fillchar() procedure, so it is not as optimized as it
> could be.

> --TCA of NewOrder
> newor...@carina.unm.edu
> http://www.nmt.edu/~surface

> Gotta love those names.

>This is a 32bit move() replacement.  Just throw the procedure in at the
>top of your program, and all your move() calls will work a little faster
>(about 4 times faster for counts above 128 bytes).

> >> >procedure FillChar (var src, dest; count : word; value : byte); assembler;

> >> >asm
> >> >  mov bx, count
> >> >  mov cx, bx
> >> >  shr cx, 1
> >>   ^^^^^^^^^^^^^^this could be a little faster by doing:
> >>    shr cx,33
> >That doesn't make any sense whatsoever.  How would you be ABLE to shift
> >right 33 bits?

> Sure it does.  There are two forms of sh[l/r].  One is a two byte, three
> clock opcode (for shifting by one..it is a throwback to the older 8088/8086
> processors), the other is a three byte, two clock opcode.  Most compilers
> will use the slower opcode when shifting by one.  (This is just the
> default it will use for shifting by one).  Any multi count shifts are
> handled by the three byte opcode.  Internally the processor will do this:
> sh[l/r] reg,count mod 32.  The mod 32 is there because the largest
> register size is 32bits, and if you were able to do something like:
> shl eax,216 it would cause massive system stalls.  By doing sh[l/r]
> reg,33 .. it will automatically use the three byte opcode (since the
> count is greater than 1) and internally only shift by one, thus saving
> you a clock.  I told you people would have a hard time understanding
> my code. :)

>>This is a 32bit move() replacement.  Just throw the procedure in at the
>>top of your program, and all your move() calls will work a little faster
>>(about 4 times faster for counts above 128 bytes).

>Um, no.  All your Move() calls where both source and destination are DWord
>aligned will be four times faster.  If either is merely word aligned, you
>will get much less than four times speedup, and if either is not even word
>aligned, you will get only a very tiny speedup.

> >> In article <Pine.SUN.3.91.950908011838.21088C-100000@verdi>,
> >> Kvantti Piikkisika  <jsha...@nmsu.edu> wrote:
> >> >Wow, and now I see why... :) but what about thhe 64-bit regs on the
> >> >Pentium? (not that I've seen any Pentium compilers yet :)

> >> There are no real 64-bit accessable registers on the pentium.  There
> >> are a few internal 64-bit regs, but they get dumped to edx:eax.

> >That's pretty lame... yeah, now I remember once reading the Pentium
> >instruction set which came with MASM6.11 (complete piece of {*word*99}, I was
> >trying it out at work) and it was funny that I don't remember any
> >extended registers, as all the 64-bit ops get put in either edx:eax or
> >into some location in memory (i.e. CMPXCHG8, or the 64-bit CMP with
> >Exchange)... what's the point of a new processor when there's no new
> >registers?!?! :)

> Backward compatibilty.  If/when you learn more about the intel processor
> you will understand why there are only 8 registers (ax,bx,cx,dx,bp,sp,si,di).
> The encoding of each instruction [that modifies a register] has a 3 bit
> field which tells the CPU which register to modify.  3 bits is only enough
> to hold 8 values (0 through 7).  To add more registers would require
> changing the lengths of the field, thus making it not backward compatable.
> The 66h prefix specifies size (doubleword in RM, word in PM).  You should
> start reading comp.lang.asm.x86.  (Note: That says READING, not posting).

> There are no real 64-bit accessable registers on the pentium.  There
> are a few internal 64-bit regs, but they get dumped to edx:eax.

> >This is a 32bit move() replacement.  Just throw the procedure in at the
> >top of your program, and all your move() calls will work a little faster
> >(about 4 times faster for counts above 128 bytes).

> Um, no.  All your Move() calls where both source and destination are DWord
> aligned will be four times faster.  If either is merely word aligned, you
> will get much less than four times speedup, and if either is not even word
> aligned, you will get only a very tiny speedup.