Author |
Topic: Possible solution for all assembler loop inc (Read 772 times) |
|
michaelgallup
Guest
|
 |
Possible solution for all assembler loop inc
« Thread started 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 |
|
 Logged
|
|
|
|
Richard Russell
Administrator
member is offline
 
Posts: 803
|
|
Re: Possible solution for all assembler loop inc
« Reply #1 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.
|
|
|
|
michaelgallup
Guest
|
|
Re: Possible solution for all assembler loop inc
« Reply #2 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..
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 803
|
|
Re: Possible solution for all assembler loop inc
« Reply #3 on: May 10th, 2016, 5:00pm » |
|
on May 10th, 2016, 2:42pm, michael wrote:
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. 
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.
|
|
Logged
|
|
|
|
michaelgallup
Guest
|
|
Re: Possible solution for all assembler loop inc
« Reply #4 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).
|
| « Last Edit: May 11th, 2016, 03:21am by michaelgallup » |
Logged
|
|
|
|
|
