BBC BASIC
Programming >> Assembly Language >> Possible solution for all assembler loop inc
http://bbcbasic.conforums.com/index.cgi?board=assembly&action=display&num=1462874936
Possible solution for all assembler loop inc
Post by michaelgallup on May 10th, 2016, 10:08am

cmp eax,ebx should compare eax and ebx

jle loop condition jump to loop. if eaz less or equal to ebx

Problem is I get "address out of range"
I cant see why.


Code:
      PRINT "Please wait for increment to 2 million"      PROCassemble      bcd%=2000000      bin%=0      REM REPEAT      CALL bin2bcd      REM UNTIL bin%=2000000      PRINT "DONE"      END      DEF PROCassemble      LOCAL P%, L%      DIM P% 12, L% -1      REPEAT        [OPT 10        .bin2bcd        mov eax,[^bin%]        mov ebx,[^bcd%]        .loop        inc eax        cmp eax,ebx        jle loop        mov [^bin%],eax        ret        ]      UNTIL bin%=2000000      ENDPROC
Re: Possible solution for all assembler loop inc
Post by Richard Russell on May 10th, 2016, 11:45am

on May 10th, 2016, 10:08am, michael wrote:
Problem is I get "address out of range"
I cant see why.

I think it's simply that you have added to your assembler code, but not increased the size of the memory you have allocated for it (still only 12 bytes!).

Given that memory is cheap, I would suggest you allocate a generous amount, and also make sure that it is well separated from the rest of the memory because of the 'SMC cache thrashing' issue which can kill performance:

Code:
      PRINT "Please wait for increment to 2 million"      PROCassemble      bcd%=2000000      bin%=0      REM REPEAT      CALL bin2bcd      REM UNTIL bin%=2000000      PRINT bin%      PRINT "DONE"      END      DEF PROCassemble      LOCAL P%, L%, gap%      DIM gap% &7FF, P% &7FF, L% &7FF      [OPT 10      .bin2bcd      mov eax,[^bin%]      mov ebx,[^bcd%]      .loop      inc eax      cmp eax,ebx      jle loop      mov [^bin%],eax      ret      ]      ENDPROC

Richard.
Re: Possible solution for all assembler loop inc
Post by michaelgallup on May 10th, 2016, 2:42pm

Thanks. I am trying to advance quickly.
I noticed that the program now instantly advances the increment to 200001
That is lightning fast..
Re: Possible solution for all assembler loop inc
Post by Richard Russell on May 10th, 2016, 5:00pm

on May 10th, 2016, 2:42pm, michael wrote:
That is lightning fast..

A modern CPU ought to be able to count to 2 million in under 10 ms (1/100 second). But as I said before, it's not doing anything useful. As soon as you incorporate any API calls (e.g. graphics) the chances are the benefit of coding in assembler will largely disappear.

This is where David Williams' GFXLIB library scored, because he coded plotting routines in pure assembler, with no API calls, so not only was it tremendously fast it was in principle portable to other platforms (e.g. Linux, Android). Just one snag: David decided to sabotage BB4W by withdrawing his library and the documentation for it. angry

All that's left now, like the grin of the Cheshire cat, is the module I coded for him: PlotRotateScaleBilinear.bbc. Pretty much useless without the rest of the GFXLIB framework. Am I bitter? You bet I am (and it's one of the main reasons why I resigned from the other forum)!

Richard.
Re: Possible solution for all assembler loop inc
Post by michaelgallup on May 10th, 2016, 9:56pm

Here is a link to the place where I am getting my more advanced information:

http://www.tutorialspoint.com/assembly_programming/assembly_arithmetic_instructions.htm

And there is an outdated book from the creators of Doom and Quake.
http://www.freetechbooks.com/michael-abrash-s-graphics-programming-black-book-t78.html

Now that you verified my suspicions concerning the assemblers abilities to access graphics directly I will focus on that immediately and work on the process here,

If you look at the Liberty Basic forums and, well pretty well every other forum in the last 20 years, the native graphics and 3D graphics advancements have not been enhanced and the entire community suffers from the lack of tools or knowledge. ( or rather, those that advanced into the 3D world are unwilling to share their secrets, like Rob, but he did make the OpenGl section, which is what utilizes his Startrek show )
Someone had to make the machine code before they could make the assembler code and someone had to make the macros for the higher languages..
I am currently studying the graphics examples in assembler. It will probably take me all week to find something that helps me dig that out.
I had a feeling that someone did figure out the small parts before the libraries could be made for Turbo Pascal.
(BGI libraries, which apparently are needed for Pelles C, if I remember correctly.
I did play with memory in the 1980s, so I know about memory locations. I also know about the dangers. Sadly, I must work with memory issues. I can gather the data and manage it, but I cant retain the detailed information. I make tools from it all.

Kinda like Peek and Poke. it has been so long.
I am going to try to crack the graphics with assembly language.
Imagine how it would have been if say the creators of Assembly language copyrighted it and only allowed special interest groups to use it, or withdrawn it and it died with them. Well, I guess someone would end up needing to do the same thing.. Make assembly language..

MASM is different than NASM... and NASM apparently has the closest dialect to BBC Basic ASM dialect.

Also, NASM has 8,32 and 64 bit related content on their pages, so that is a plus. (And they have a forum too. There is a fair amount of activity there but I cant get in. They have links to graphics, but some links don't exist anymore.)
I tried on Microsoft servers, but they are, like usual not the most user friendly site to learn anything (for me at least that has always been true).