Optimizing and type-casting constants?

[Criss French]

Ok, a sudden deadline of two days is upon me, and I have to now convert and do big changes to my old QB3.5 survey software. Glad I've had the PB3.5 manuals in paper in the bathroom for the last two years, and have read them several times through. Let's see if anything stuck

Speed is fairly important in several parts of my program. I need to keep up with a couple of realtime serial data streams. So I have been coding, with a mind to those pesky little details like implied conversions and efficient data types. So here's the question:

Does PB3.5 optimize numeric contstants at compile time to prevent implied conversions? I am trying to write strongly typed code, and would like to know if I am being anal-retentive. Below is an example. Notice the stuff like 1%, 3%, etc. This is intended to avoid a conversion from byte (unsigned) to integer (signed). would the compiler take care of that anyways? Am I just wasting my time?

for cc% = 1% to ln%

  n%=ascii(mid$(n$, cc%, 1%))

  select case n%
  case 48% to 57%  ' "0" thru "9"
    p% = n%-48% : col% = col% + 4%
  case 45%         ' "-"
    p% = 10% : col% = col% + 4%
  case 46%         ' "."
    p% = 11% : col% = col% + 3%
  case 69%, 101%   ' "E" or "e"
    p% = 12% : col% = col% + 4%
  case 43%         ' "+"
    p% = 13% : col% = col% + 4%
  case 32%         ' space
    p% = 14% : col% = col% + 4%
  case else        ' anything else does a thin underscore
    p% = 15% : col% = col% + 4%
  end select

  for rc% = 0% to 4%
    locate (row% + rc%), col%
    print mid$(p$(p%), 1% + (rc% * 3%), 3%);
  next rc%

if n% = 46% then col% = col% - 1%

next cc%

------------------
What can go wrong will go wrong.
Anything can go wrong.
What hasn't?!?!

[Criss French]

Oh, more questions for someone who knows.

- What are the numeric parameter types of the various PB functions like mid$/left$/right$, chr$, locate$? It would seem to be integer%. Still just trying to hand things exactly what they want...

- The book says that numeric constants are stored in the smallest type that will hold the value as typed. That means that going mid$(a$,5,3) will store the 5 & 3 as bytes, but need to promote them at run time to hand over to mid$. Or does it?...

- When compiling using NPX, does the x87 handle smaller floating point data types too? I know its registers are extended size, but can it just use smaller floats directly, or is there a big conversion penalty. I could use ## for all larger floats, but it's a little mem hoggish for arrays where ! or # will do.


------------------
What can go wrong will go wrong.
Anything can go wrong.
What hasn't?!?!

[Lance Edmonds]

First, I'd use a byte pointer to analyse the bytes in the string, since that will almost certainly be faster than a ASC\+MID$ loop.

Next, SELECT CASE in PB/DOS has to cast most test values to extended precision so for time-critical code, using a IF/ELSEIF block might offer slightly better speed... you'd need to behcnmark it yourself to determine the best approach for your specific needs.

However, in either case, placing the most likely cases first in the block will help execution time.

What are the numeric parameter types of the various PB functions like mid$/left$/right$, chr$, locate$? It would seem to be integer%. Still just trying to hand things exactly what they want

In PB/DOS, strings can only be a maximum of 32750 bytes, and partial bytes are not possible, so integer values are what are used.

The book says that numeric constants are stored in the smallest type that will hold the value as typed. That means that going mid$(a$,5,3) will store the 5 & 3 as bytes, but need to promote them at run time to hand over to mid$. Or does it?...

In the context of use with MID$, etc, PB will automatically use integer data types so no runtime casting is required there.

When compiling using NPX, does the x87 handle smaller floating point data types too? I know its registers are extended size, but can it just use smaller floats directly, or is there a big conversion penalty. I could use ## for all larger floats, but it's a little mem hoggish for arrays where ! or # will do.

The NPX is used for all virtually all floating-point math if you specify $FLOAT NPX.

I hope this helps!

PS: for the lurkers, implicit and explicit SELECT CASE optimizations are more advanced in the Windows range of PowerBASIC compilers than PB/DOS.


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Tom Hanlin]

The best way to resolve a question of whether one approach is faster
than another is, try them both and time them.


------------------
Tom Hanlin
PowerBASIC Staff

[Criss French]

Lance and Tom: Thank you very much for such fast replies. Muchly appreciated.

One more question:

The NPX is used for all virtually all floating-point math if you specify $FLOAT NPX.

Still curious: does the x87 use ! and # types directly, or do they get converted to ##, worked on, then converted back? I know the x86 can natively handle a few different size operations, but does the x87? And which way does PB handle the matter?

I know these are kind of general machine code related questions, but I got PB because I don't want / know-how to do assembly. I very much appreciate how much PB facilitates this work, and it keeps giving me wise and gentle nudges to learn more. Very supurb framework for it.

Thanks again



------------------
What can go wrong will go wrong.
Anything can go wrong.
What hasn't?!?!

[Tom Hanlin]

I'll have to submit that one to R&D...

------------------
Tom Hanlin
PowerBASIC Staff

[Jerry Mason]

The numeric coprocessor always converts to its native numeric data type (10 bytes). The conversion to and from the original type is done during loading and storing, so there is no way around it.

------------------

[George Bleck]

And I thought I was the only one that had a PB library in the throne room

------------------
Every day I try to learn one thing new,
but new things to learn are increasing exponentially.
At this rate I’m becoming an idiot faster and faster !!!
------------------
George W. Bleck
Lead Computer Systems Engineer
KeySpan Corporation