www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1995/02/04/14:26:37

Date: Fri, 03 Feb 1995 14:11:47 EST
From: THE MASKED PROGRAMMER <badcoe AT bsa DOT bristol DOT ac DOT uk>
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Cc: badcoe AT bsa DOT bris DOT ac DOT uk
Subject: 256x256 look up optimisation

Hi,

Sorry about the delay to this but I've been away having a baby (or
rather my wife has):

<mat AT ardi DOT com wrote>

> When asking for help with an algorithm, it is helpful if you can
> formulate the problem in simple terms.  From looking at your code, it
> looks like your problem is "I want to map an array of 16 bit values to
> an array of 8 bit values via a 64K lookup table as quickly as
> possible".  Is this a fair assessment?  

Yes and No.  The *real* problem is with a 256*256 array, I treat that
as a 64K lookup on the assumption that its more efficient.  I didn't
want to imply that the 64K table was obligatory in case anybody knew
better.

> This is a much different
> statement than your original question, which unnecessarily brought up
> two dimensional arrays.

Surely a 256x256 array and a 64K array are the same thing (unless you
think of 256x256 as table[256][256] but I thought I said that in the
first posting (which may not be the one you were reading)).

> I have a question for you: does %es refer to conventional memory (so
> you can access the VGA frame buffer), or is all of this taking place
> in PM memory?

Do you mean %esi ?  It's in PM memory, I think (in retrospect) that all
my references to RM and PM were spurious.

> I noticed a few efficiency problems with your code,

What were they ?

> although to be
> honest I don't know much about optimizing for the 80386 in particular.
> Do you want this to be fast on all x86's or do you only care about the
> 80386?

It has to "at least" work on the 386 ('cos that's what I have).

Thanks


Badders

- Raw text -


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