• State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 22 subscribers
  • Views 1265 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

_init_boxh problem

Peter Morisse

I'm trying to use the _init_boxh() function but the function always fails.

When I look into the assembler code I noticed that the _init_boxh() routine is not support. 64Ksegment length huge pointers, but using the 16Ksegment far memory model instead when it is testing the memory space:

// example, calling function:
// use 0x1000 block at 0x11F000
_init_boxh(0x11F000,0x1000,0x100)

MOV R11,#0x0100
MOV R10,#0x1000
MOV R8,#0xF000
MOV R9,#0x0011
CALLS _init_boxh(0x2B7E8)

(0x2B7E8): _init_boxh() routine:
MOV R4,#0x00
ADD R11,#1
AND R11,#0xFFFE
JMPR CC_Z,0x02B828
ADD R10,R8 => NOT VALID in 64Kspace => cc lost!!
MOV R6,R8
MOV R5,R8
ADD R6,#6
SUB R10,R11
JMPR CC_C,0x02B828
=> exits here because R10 < R11

Parents
  • 0 in reply to Mik Kleshov

    The asm code printed is the code from the _init_boxh() routine, NOT mine!

    The internal code of the function is hitting the 64k boundary by adding the pool size with the segment offset.
    I, as a user of the _init_boxh() function, doesn't hit any 64K boundary.
    I allocated a static huge 0x1000 byte block and gave the returned pointer to the _init_boxh() function:

    #define BLOCK_POOL_SIZE 0x1000
    char huge *block_pool[BLOCK_POOL_SIZE];

    main
    {
    ...
    _init_boxh(block_pool,BLOCK_POOL_SIZE,0x100);
    ...
    }

    And block_pool pointer showed 0x11F000 value when I was debugging.

    How should I call this function then?

    I've made a work around by using _init_boxf() instead (far-version), and casting my pointers to (void far *).

    main
    {
    ...
    _init_boxf((void far *)block_pool,BLOCK_POOL_SIZE,0x100);
    ...
    }

Reply
  • 0 in reply to Mik Kleshov

    The asm code printed is the code from the _init_boxh() routine, NOT mine!

    The internal code of the function is hitting the 64k boundary by adding the pool size with the segment offset.
    I, as a user of the _init_boxh() function, doesn't hit any 64K boundary.
    I allocated a static huge 0x1000 byte block and gave the returned pointer to the _init_boxh() function:

    #define BLOCK_POOL_SIZE 0x1000
    char huge *block_pool[BLOCK_POOL_SIZE];

    main
    {
    ...
    _init_boxh(block_pool,BLOCK_POOL_SIZE,0x100);
    ...
    }

    And block_pool pointer showed 0x11F000 value when I was debugging.

    How should I call this function then?

    I've made a work around by using _init_boxf() instead (far-version), and casting my pointers to (void far *).

    main
    {
    ...
    _init_boxf((void far *)block_pool,BLOCK_POOL_SIZE,0x100);
    ...
    }

Children
  • 0 in reply to Peter Morisse

    One thing is confusing me. You wrote:

    char huge *block_pool[BLOCK_POOL_SIZE];
    whereas I believe it should be:
    char huge block_pool[BLOCK_POOL_SIZE];
    Must be a typo in the post.
    Anyway, I see the point your are making. I admit, I didn't see it at first. Basically, the problem is that you are allocating the buffer as a huge array and passing a pointer to it to the function which should be happy with it since we don't expect compiler/linker to allocate huge objects that would cross a 64K boundary.
    It seems that in this particular case the upper boundary of the buffer "touches" a 64K boundary which upsets 16-bit address arithmetics in _init_boxh(). It's not clear to me whether _init_boxh() should be prepared to deal with such situations. It probably should.
    As a workaround, I would suggest allocating the buffer in such a way that its upper boundary doesn't touch a 64K boundary. It could be as easy as this:
    char huge block_pool[BLOCK_POOL_SIZE+1];
    although it's not guaranteed to work. The bulletproof approach would be to combine the buffer in a union with an array of ints and making sure that the buffer size in bytes is odd.

    - mike

  • 0 in reply to Mik Kleshov

    A correction to my last post:

    although it's not guaranteed to work

    After thinking about it a minute, it is guaranteed to work. But I could still be missing something, of course.

    Regards,
    - mike