Announcement

**Michael Mattias** · 15 May 2001, 05:50 AM

Three possible fixes

1.The UDT may need DWORD alignment to work.

2 Instead of opening the file RANDOM with a recordlen = LEN(something), open it with SIZEOF(something)

3. Instead of opening the file RANDOM, open it BINARY and SEEK to the correct location...

Code:

OPEN File$ FOR BINARY AS F BASE=0
' BASE=0 is what I use. It's what previous compliers used. YMMV)

   SEEK #F, (RecNo% - 1) * SIZEOF(UDTtoGrab)
   GET #F,,UDTToGrab
   ...

MCM

**Lance Edmonds** · 15 May 2001, 06:04 AM

First, 32-bit VB uses "natural alignment" in it's UDT's... meaning that the members are not strictly DWORD aligned, but packed and aligned depending on the size of each member. There is an FAQ in the FAQ Forum on using VB UDT's with PowerBASIC.

Importantly, in the 32-bit world, LONG integers are usually always faster than 16-bit integers.

Beyond this, there is no way we can "guess" what else could be causing a bottleneck in your code.

Have you reviewed the section in the help file on optimizing your code? Are you using register variables for loop counters, etc?

PS: I've read and reread your last paragraph but I'm afraid your last paragraph is lost on me... a well written WIN32 app is almost guaranteed to be faster than the equivalent 16-bit code. Stability of an application is really a function of how well the programmer wrote the code - be it DOS, WIN16, WIN32 or otherwise.

As you work more and more in the 32-bit domain, you should start to see the [speed and coding] advantages of flat memory addressing, etc. However, if you write "bad" WIN32 code or do minimalist 16-bit code ports, then you probably won't reap any significant benefits since you may be ignoring the simple optimizations that can help you app performance.

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

**Tom Hanlin** · 15 May 2001, 10:44 AM

After a week of fighting, I have my application converted and 60% operational
in 32bit VB5 and PB6.. Though I noticed it is a great deal slower
than the 16bit counterpart..Why?

Without seeing the source code, there's no way of knowing. Generally, 32-bit code is
faster for a variety of reasons. It is likely that your translation does not take
full advantage of the 32-bit environment, since you are not that familiar with it yet.
32-bit versions of Visual Basic can be inefficient in many respects, due to the use
of Unicode strings (which may be translated to/from ANSI on the fly), Variant support
(meaning slower expression evaluation), and suchlike issues that won't be immediately
obvious.

I also noticed that there are errors in reading UDT's with integer
variables.. I have this UDT that I am reading from a .DAT file..

Your PowerBASIC code is reading the UDT correctly. The problem is actually in passing the
result to Visual Basic. Here's the scoop.

In 16-bit code, structure alignment is not an issue. Both VB and PowerBASIC use byte
alignment, which is also commonly supported by other languages.

In 32-bit code, unfortunately, alignment gets a little weird. PowerBASIC still supports
traditional alignment methods, including byte alignment (still the default). VB only
supports a single alignment, oddly described by Microsoft as "natural" alignment. With
this approach, the alignment of any member of a type depends mostly on the size of that
member. Alignment handling also changed from VB5 to VB6. So... it's a bit of a hassle
to pass UDTs between PowerBASIC and 32-bit VB, unless you have carefully designed the
UDT or have different UDTs for PB and VB, with appropriate padding members in the PB
version.

For more information on VB's packing methods, see:
http://support.microsoft.com/support.../q249/9/62.asp http://msdn.microsoft.com/library/de..._alignment.htm

The first link describes the difference in packing from VB5 to VB6.
The second link is the key doc on Microsoft's 32-bit alignment techniques,
although it's written with C in mind.

When programming in 32bit, does it mean that I can't use INTEGERS at all?
Should I global search and replace all % with ! and INTEGER with
LONG?

You can use INTEGERs all you like. LONGs are somewhat more efficient in 32-bit code,
though.

Right now the 32bit platform seems like its still in beta testing
and really not suitable for developing on..(under windows) I honestly haven't seen
any Windows applications (32bit) that were 100% stable..

The 32-bit platform has been out for a long time and is inherently more stable than
the 16-bit platform. The problems you are experiencing are not a result of instability
in the platforms, but because you are new to the 32-bit environment. It's not
identical to 16-bit, of course. That doesn't mean it's broken, just that you need to
learn what the differences are in order to exploit them properly.

And one last question.. The 32bit platform is really a software integration
correct? Meaning the physical computer chip is managing 16bit?
Because if I drop to ASM and began to load addresses the chip
will not allow me to load a 32bit value correct?

I'm not entirely sure what the question is, here, but try this answer and see how it
fits. In 16-bit code, an address is composed of a 16-bit segment and 16-bit offset,
which were combined by the computer into a 20-bit address. This allowed a maximum of
1 Mb of directly accessible memory, and a segment only covered a range of 64 Kb.

On 32-bit platforms (such as Windows 95/98/Me, NT, Windows 2000), the processor is in
32-bit mode, using flat addressing. In this case, the address is effectively composed
of a 32-bit offset, and you don't fiddle with segments at all. You can directly address
up to, mmmm, at least 2 Gb in theory. Much simpler and more direct. Also faster.

That's the short and sweet summary, to be sure. EMS, XMS, virtual memory, allocated
vs committed memory, segments versus selectors... well, there is much that is useful
to know about memory management on many levels. It's a good topic to study, although
it's generally possible to get along well enough without knowing too much about it.

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

**Tyrone W. Lee** · 18 May 2001, 10:30 AM

Well I guess I don't understand how/why 32bit would be soo slow on my
computer.. I am sure there are places that the code could be
optimized but my point is : How can 16bit (unoptimized) code run
slower than 32bit (unoptimized) code?

All the routines are exactly the same. The logic behind them as well
as the order of operations.. So, the only REAL difference is
the datatype. (INT) vs (LONG) - To me, that is the ONLY difference
between 16bit / 32bit..

If datafiles can be read accurately on a 16bit platform but will
read inaccurately on a 32bit platform then there is a flaw in the
design.. ELSE - Whats the point of a DataType?

I will switch all values to LONG and see if this speeds things up,
else its seems like nobody will truely be able to answer the
questions I have... Thanks anyway guys..

------------------
Explorations v3.0 RPG Development System
http://www.explore-rpg.com

**Tom Hanlin** · 18 May 2001, 11:35 AM

You're thinking of 32-bit as being the same as 16-bit, only wider. In truth, it's more like
a completely different platform that was designed to make 16-bit programmers feel a little bit
at home. It's very similar to the 16-bit world by design, but it's really a whole new ball game.

The fact that your routines are the same at the source code level doesn't mean anything at all.
You're dealing with completely different compilers, API calls, CPU mode, drivers, the works.

The point of a data type is to allow you to store data. You were never guaranteed that the data
would be stored in exactly the same way with different compilers, or that they would be passed
from one language to another in any given fashion. (Time was, you were pretty much guaranteed
that the data would never be portable: the current level of standardization was actually
brought to you courtesy of Microsoft, but consistency is not among their virtues.)

If you expect to deal well with the 32-bit world, you'll need to learn more about it. That's kind
of what programming's all about, of course. If that's not for you, I don't see anything terribly
wrong with sticking with 16-bit code. In either case, you'll have to face limitations. The 32-bit
world has far fewer of them, as near I can see, but it isn't ever going to behave in quite the
same way as the 16-bit world to which you've grown accustomed.

If you have a specific question, someone can probably help you with it. A question on the order of
what could cause 32-bit code to be slower than 16-bit code is far too general. What code, exactly?
On what processor? And what operating system? Show us the source code and perhaps someone can
show you a better solution.

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

Announcement

16bit/32bit conversion question..

16bit/32bit conversion question..

Comment

Comment

Comment

Comment

Comment