Announcement

Collapse
No announcement yet.

16bit/32bit conversion question..

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 16bit/32bit conversion question..

    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?

    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..

    Type CharType
    Hnd As STRING * 40
    Icon As String * 20
    newIcon As String * 20
    Script As String * 40
    AI_Status as Integer
    Mobility as Integer
    Named As String * 40
    Status As Statustype
    expr as Long
    Class as Integer
    Race as Integer
    gold as Long
    Skills(30) as Integer
    Armor(4) As obj
    Weapons(10) As obj
    Equipment(30) As obj
    Spells(50) As obj
    Hidden(100) As obj
    End Type

    When this record is read in 32bit The Class=1
    and the Race=1 for a specific record. The 32bit version read the
    values as 1 and 75 respectively.. I also noticed
    that the expr value has some random number in it. Like 234533..This is horrible!

    I read the record from this PB .DLL routine..

    SUB ReadCharacter ALIAS "ReadCharacter" (BYVAL Rec%, file$, vbObject AS CharType) EXPORT
    DIM fl%

    ON ERROR RESUME NEXT
    IF Rec% > 0 THEN
    fl% = FREEFILE

    OPEN file$ FOR RANDOM ACCESS READ AS fl% LEN = LEN(CurrentPlayer)
    GET #fl%, Rec%, CurrentPlayer
    CLOSE fl%
    END IF
    vbObject = CurrentPlayer
    END SUB

    I rechecked the datatype to make sure everthing was Ok.. (it was)
    I reverted back to the 16bit version of the application to
    see if the UDT loaded correctly.. (it did)

    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?

    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..


    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 am unclear of
    what 32bit really means.. for years people have said that it meant
    "speed" but from my experiences it doesn't..



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

  • #2
    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

    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]s.com
    http://www.talsystems.com

    Comment


    • #3
      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>
      Lance
      mailto:[email protected]z

      Comment


      • #4
        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

        Comment


        • #5
          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
          Explorations v9.10 RPG Development System
          http://www.explore-rpg.com

          Comment


          • #6
            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

            Comment

            Working...
            X