Fun with CALL ABSOLUTE

[NOVARSEG]

Some fun with CALL ABSOLUTE
code not tested. Maybe someone might try to get it to work?

DIM apple AS LONG ' 4bytes
DIM string AS STRING * 20 'reserve space for ASM code

DEF SEG = VARSEG(apple)
FOR x% = 0 to 11
READ d%

DATA &h66,&hb8,&ha0,&h86,&h01,&h00,&h66,&ha3,&h00,&h00,&hcb"
POKE (VARPTR(apple) + 4 + x%),d%)
next x%
CALL ABSOLUTE(VARPTR(apple) + 4)

DEF SEG  'put DS where it was

PRINT apple  ' should = 100000
****

here is the assembler code  encoded in the DATA
'mov eax,100000
'mov [[0]],eax  'the single brackets would not show on the site so had to use 2 brackets.
'RETF
****
 
In mov [[0]],eax   the offset might not be zero.  In Quick Basic the offset is 6 If DS was pointing to start of BC_DATA segment. 

got the idea from https://scruss.com/qbasic_hlp/T008A.html

here is a site where you can disassemble code  http://shell-storm.org/online/Online-Assembler-and-Disassembler/?inst=mov+ax%2C0%0D%0Aretf&arch=x86-16&as_format=inline#assembly

Quite a few of the online assemblers put a 66h in front of  an opcode when it shouldn't - be careful!

**** So QB knows where the variable "apple" is in memory but the ASM code does not really know unless the offsets are predictable.

[luke]

Watching you on this pointless crusade to use 16 bit memory commands is painful, like watching a person trying to shoot themselves in the foot but unsure how to load and fire a gun. Please stop.

[SMcNeill]

Watching you on this pointless crusade to use 16 bit memory commands is painful, like watching a person trying to shoot themselves in the foot but unsure how to load and fire a gun. Please stop.

+1

[bplus]

Hey when your avatar name is NOVARSEG?

Is that a complaint?

Can't be: http://www.qb64.org/wiki/VARSEG

I suspect this forum a last Bastian of true QBasic die-hards.

There is this: http://masm32.com/board/index.php?topic=8287.0
Maybe NOT that particular board but the forum has a guy working on Basic for Masm.
I met jj2007 at BP.org

Here this Board, maybe?
http://masm32.com/board/index.php?board=57.0

[Pete]

We had a guy post at The QBasic forum some months ago who used this stuff extensively in game programs. The were really very ell built games, but because of his reliance on what I call address programming, there was no way to convert what he made to QB64 without a complete rewrite of several hundreds of lines of code.

LOL@luke's comment. Gave up on dry humor?

@footshooter: I'm glad you like the 16-bit stuff, and there was a time when the push to get QB64 100% QB compatible was of greater importance. There was a push that succeeded in limited support for some library functions but because there were so many as well as QB "features" like DEF FN, eventually the push fell by the wayside. Further development  was probably deemed just too much time and trouble for the limited use and at least DEF FN has a straight forward way for coders to put those statements into traditional functions. Rob did include CALL INTERRUPT mouse support in QB64, which can be used in place of the CALL ABSOLUTE mouse routines; but I get it, we all miss some of the older 16-bit stuff at times, especially if a large completed program can no longer be resurrected. QB64, of course, has its own mouse keywords, too.

Pete

[SpriggsySpriggs]

Watching you on this pointless crusade to use 16 bit memory commands is painful, like watching a person trying to shoot themselves in the foot but unsure how to load and fire a gun. Please stop.

++++++1

[SpriggsySpriggs]

Some fun with CALL ABSOLUTE
code not tested. Maybe someone might try to get it to work?

Why not test it first yourself? You know what the code is trying to accomplish and why it is written in such a fashion.

[bplus]

What is the attraction? Is it the 16 bit simplicity or getting down close to assembler calls, I thought it was the later.

If it's 16 bit simplicity that is like preferring screen 0 over _NEWIMAGE(yourWidth, yourHeight, 32 = millions of colors for all kinds of graphics) ;-))

But screen 0 still has purpose.

[Pete]

If it's 16 bit simplicity that is like preferring screen 0 over _NEWIMAGE(yourWidth, yourHeight, 32 = millions of colors for all kinds of graphics) ;-))

Now you're getting it!

Pete :D

SCREEN 0, the only screen any real programmer would ever need.

[NOVARSEG]

OK thanks everyone.

That was the first time I used CALL ABSOLUTE.  These types of commands were popular in the day.

QB64 supports CALL ABSOLUTE. so that is the main reason I posted.

I think this CALL ABSOLUTE could be used for fast string operations

say two strings are dimensioned like:

DIM string1 AS STRING * 16384
DIM string2 AS STRING * 16384

The code I posted is basically a way to access these strings through ASM code.

Example, lets say you want to encrypt string2 by XORing the bytes in string1 with string2

The ASM code can do that as long as it knows the location of the DIMed strings.

[bplus]

Well now I wonder if _MEM stuff doesn't give same access to the bits and bytes to analyse and process strings fast!

[NOVARSEG]

what is the best way to XOR the bytes in string2 with bytes in string1?

I was thinking of using MID$ (in quick basic) but from past experience that is too slow

how do you use the memory functions in QB64 to do that.

DIM string1 AS STRING * 16384
DIM string2 AS STRING * 16384

Procedure is to get the first byte from string1 and store it  in  A%. Then get the first byte from string2 and XOR it with A%. Then replace the first byte of string2 with A%

Repeat for every byte.

[SMcNeill]

DIM string1 AS STRING * 16384
DIM string2 AS STRING * 16384

DIM m1 AS _MEM, m2 AS _MEM
DIM b1 AS _BYTE, b2 AS _BYTE
m1 = _MEM(string1): m2 = _MEM(string2)

FOR i = 0 TO 16383
    _MEMGET m1, m1.OFFSET + i, b1
    _MEMGET m2, m2.OFFSET + i, b2
    b3 = b1 XOR b2
    ‘Do whatever you want with b3 
NEXT

(Though in this case, I’d read as _UNSIGNED _INTEGER64’s, to reduce processes by 1/8th.)


I direct all questions to my mem video series.  I suggest starting there.  https://www.qb64.org/forum/index.php?topic=1731.0

[NOVARSEG]

SMcNeill

Thanks.  Looking at _MID in the wiki.

Watching your videos. That is interesting on how binary file access is similar to _MEM

XOR 8 bytes at a time would be fast.

[bplus]

ASC(String$, i) will get you numbers instead of letters fast! as opposed to MID$(String$, start (strings are base 1), lengthOfSlice) which will give a slice of the string.