• State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 21 subscribers
  • Views 1211 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

    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

Reply
  • 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

Children