• State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 21 subscribers
  • Views 1213 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

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 Peter Morisse

    You are saying you don't understand where you are hitting a 64K boundary, but the rest of your post explains exactly where you do. "Crossing a 64K boundary" means having a carry in 16-bit arithmetics, and that's exactly what's happening in your case (0x11F000+0x1000=0x120000: here is your carry.)

    - mike

Reply
  • 0 in reply to Peter Morisse

    You are saying you don't understand where you are hitting a 64K boundary, but the rest of your post explains exactly where you do. "Crossing a 64K boundary" means having a carry in 16-bit arithmetics, and that's exactly what's happening in your case (0x11F000+0x1000=0x120000: here is your carry.)

    - mike

Children
  • 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);
    ...
    }

  • 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