Jump out of range?

[Byron Blue]

When I try to compile this inline assembly I get the same error on three
lines: 362, 443 and 502 Error! E1156: Assembler error: 'Jump out of range'.
I have likely done something very basically wrong - I've been coding C for
years but am rather new at inline assembly.
Any help would be appreciated.
Thank you,

Byron Blue

[Byron Blue]

Thanks to The Art of Assembly Language I have gained some understanding of
this issue: At least I believe I have.
Apparently conditional jumps generate an 8 bit displacement - 127 bytes.
The solution seems to be using the opposite branch:
cmp ch, cl
jne TARGET
would become
cmp ch, cl
je OVER
jmp TARGET
OVER:
(blah, blah, blah)...
TARGET:

The jmp instruction allows 16 bit displacement and far operands - the trick
will overcome the issue.
Thanks for consideration and I hope this may help some other newbie like
myself.
Byron

"Byron Blue" wrote in message news:ksossi$qks$***@www.openwatcom.org...

When I try to compile this inline assembly I get the same error on three
lines: 362, 443 and 502 Error! E1156: Assembler error: 'Jump out of range'.
I have likely done something very basically wrong - I've been coding C for
years but am rather new at inline assembly.
Any help would be appreciated.
Thank you,

Byron Blue

[Byron Blue]

Ok. No that did not remove the error (tried it on the L$17).
Hmmm,
Byron

"Byron Blue" wrote in message news:ksp496$seo$***@www.openwatcom.org...

Thanks to The Art of Assembly Language I have gained some understanding of
this issue: At least I believe I have.
Apparently conditional jumps generate an 8 bit displacement - 127 bytes.
The solution seems to be using the opposite branch:
cmp ch, cl
jne TARGET
would become
cmp ch, cl
je OVER
jmp TARGET
OVER:
(blah, blah, blah)...
TARGET:

The jmp instruction allows 16 bit displacement and far operands - the trick
will overcome the issue.
Thanks for consideration and I hope this may help some other newbie like
myself.
Byron

"Byron Blue" wrote in message news:ksossi$qks$***@www.openwatcom.org...

When I try to compile this inline assembly I get the same error on three
lines: 362, 443 and 502 Error! E1156: Assembler error: 'Jump out of range'.
I have likely done something very basically wrong - I've been coding C for
years but am rather new at inline assembly.
Any help would be appreciated.
Thank you,

Byron Blue

[japheth]

Post by Byron Blue
Ok. No that did not remove the error (tried it on the L$17).
Hmmm,

The hint from AoA targets 16-bit code. Your code is 32-bit - in 32-bit there's
no 127/128-byte distance restriction for conditional jumps.

you could try to modify:

"jne L$17"\

to

"jne near ptr L$17"\

However, this is a wild guess - I'm not familiar with OW inline assembly.

[Byron Blue]

Thank you Japheth
Adding NEAR PTR did the trick.
Unfortunately the code is not as quick as I would like but I now have a
starting point to work from - and a bit more understanding of inline
assembly.
Again, I thank you for your assistance,
Byron

Post by Byron Blue
Ok. No that did not remove the error (tried it on the L$17).
Hmmm,

The hint from AoA targets 16-bit code. Your code is 32-bit - in 32-bit
there's
no 127/128-byte distance restriction for conditional jumps.

you could try to modify:

"jne L$17"\

to

"jne near ptr L$17"\

However, this is a wild guess - I'm not familiar with OW inline assembly.

[Byron Blue]

I've determined that the floating point math to calculate the X and Y pixel
positions is causing the speed bottleneck. Ongoing...

"Byron Blue" wrote in message news:ksr3nk$7b4$***@www.openwatcom.org...

Thank you Japheth
Adding NEAR PTR did the trick.
Unfortunately the code is not as quick as I would like but I now have a
starting point to work from - and a bit more understanding of inline
assembly.
Again, I thank you for your assistance,
Byron

Post by Byron Blue
Ok. No that did not remove the error (tried it on the L$17).
Hmmm,

The hint from AoA targets 16-bit code. Your code is 32-bit - in 32-bit
there's
no 127/128-byte distance restriction for conditional jumps.

you could try to modify:

"jne L$17"\

to

"jne near ptr L$17"\

However, this is a wild guess - I'm not familiar with OW inline assembly.

[Steve Fabian]

Byron Blue wrote:
| I've determined that the floating point math to calculate the X and Y
| pixel positions is causing the speed bottleneck. Ongoing...

Are you familiar with "scaled" (fixed point) arithmetic? In each 32b value
you have an implied binary point, i.e., always consider the low order part
(e.g. 18b) as the fraction part. You need to keep track where the binary
point is after multiplication or division - mentally, or - my preference -
by comments in the code; addition and subtraction don't move it. Before fast
and cheap FPUs became available, ALL real time programs used them, whether
medical, navigation, or power control. More effort in design will as usual
produce better product.

[Byron Blue]

Thanks Steve
I had just been looking into bit-shifting my tables and values to be able to
use them as integers ( xPosition and yPosition are screen positions).
I've used this technique once before for maintaining precision in MMX
assembler (it does not handle floating point).
And thank you for putting a name to the technique for me.
Much appreciated,
Byron

"Steve Fabian" wrote in message news:ksr7nn$ekn$***@www.openwatcom.org...

Byron Blue wrote:
| I've determined that the floating point math to calculate the X and Y
| pixel positions is causing the speed bottleneck. Ongoing...

Are you familiar with "scaled" (fixed point) arithmetic? In each 32b value
you have an implied binary point, i.e., always consider the low order part
(e.g. 18b) as the fraction part. You need to keep track where the binary
point is after multiplication or division - mentally, or - my preference -
by comments in the code; addition and subtraction don't move it. Before fast
and cheap FPUs became available, ALL real time programs used them, whether
medical, navigation, or power control. More effort in design will as usual
produce better product.