From:	qball1723 AT aol DOT com (QBall1723)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: DJGPP too slow!
Date:	25 Nov 1997 00:22:44 GMT
Lines:	108
Message-ID:	<19971125002200.TAA04254@ladder02.news.aol.com>
NNTP-Posting-Host:	ladder02.news.aol.com
Organization:	AOL http://www.aol.com
References:	<34773B8D DOT B6D38BF9 AT lr DOT net>
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

>Subject: Re: DJGPP too slow!
>From: Isaac Waldron <waldroni AT lr DOT net>
>Date: Sat, Nov 22, 1997 15:07 EST
>Message-id: <34773B8D DOT B6D38BF9 AT lr DOT net>
>
>Fabrice ILPONSE wrote:
>
>> Hi!
>> Here's the topic back.
>>
>>         That time have made a new test concerning video memory access.
>>
>>         TEST: DISPLAY THE DATA SEGMENT/SELECTOR directly to the video
>memory
>> (BLIT) 32000 words.
>>
>>         For comparison: BC 3.1 and DJGPP.
>>
>>         Befor ALL: even in BC 3.1, i've used 32 bits inline assembly.
>>                    i haven't used any existing libraries!
>>
>>         The  PROG:
>>
>>                 - switch to video mode 320x200x256
>>                 - loop
>>                         - change color 0 to red
>>                         - BLIT
>>                         - change color 0 to black
>>                         - wait retical retrace
>>
>>         I've got a 486 DX2 66.
>>
>>         Results:
>>                 - BC 16 bits red takes  40% of screen height
>>                 - BC 32 bits 45 - 50%
>>                 - DJGPP      90 - 95%
>>
>>         Those values are approximated. (humain looking)
>>
>>         I repeat it, i do not say anything about the djgpp generated code.
>I
>> think it's as good as the BC one. But what else can slow down the
>> performances?
>>
>>         Protected mode perhaps!
>>
>>         SOON: i'll  try to do the same under my modified protected mode BC
>3.1
>> version.
>>
>> Bye
>> --
>>         ^ ^ ^
>>         | | |
>>         +-+-+   Fabrice ILPONSE
>>           |     <fabrice AT asim DOT lip6 DOT fr>
>>           |
>>           |
>>           -
>
>  I had sort of the same problem with my 3D graphics program.  I was using a
>for
>loop to call _farpokeb(blah) 64000 times.  As you can probably figure, this
>was
>quite slow.  However, when I switched to using movdata(blah) for both
>blitting a
>page and clearing my draw_buffer, my program was suddenly 5 times faster!
>movedata() is very well optimized, and so it works well for blitting pages to
>vid
>mem.

Here are a couple of macros I found at a DJGPP assembly FAQ somewheres.... I've
posted them elsewhere... as part of a reply to someone else's question...

    ...perhaps it's psychological... but I believe these will clear (set) and
copy memory faster than the library function move_data... or dosmemput (I
believe dosmemput only uses bytes... but I'm not certain of this...)

// MACRO FOR 32 BIT MEMORY MOVE (used to copy double_buffer to
// video_buffer

#define rep_movsl(src, dest, numwords) \
__asm__ __volatile__ ( \
  "cld\n\t" \
  "rep\n\t" \
  "movsl" \
  : : "S" (src), "D" (dest), "c" (numwords) \
  : "%ecx", "%esi", "%edi" )

// MACRO TO SET BITS (32-bits at a time), used in filling the double
// buffer using LONG WORDS ; ]

#define rep_stosl(value, dest, numwords) \
__asm__ __volatile__ ( \
  "cld\n\t" \
  "rep\n\t" \
  "stosl" \
  : : "a" (value), "D" (dest), "c" (numwords) \
  : "%ecx", "%edi" )


  I hope someone is finding these macros useful.... if anyone has better -
please share it with me!


Jim the loiterer
http://members.aol.com/qball1723/index.htm
(wannabe PC game/graphics developer)

- Raw text -