| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
Questions about Basic-statements and logic
Hi,
//PW is DIM-table to {1,2,4,8,16,32,64,128}
210 B1 = PW(7-D0)
212 B2 = PW(R7)
214 B3 = PW(7-D1)
220 P1 = (PEEK(W+B) AND B1) / B1
222 P2 = (PEEK(W+A) AND B2) / B2
224 P3 = (PEEK(W+C) AND B3) / B3
I changed 220, 222 and 224 to:
220 P1 = (PEEK(W+B) AND B1)
222 P2 = (PEEK(W+A) AND B2)
224 P3 = (PEEK(W+C) AND B3)
and added the lines:
226 IF P1=B1 THEN P1=1
227 IF P2=B2 THEN P2=1
228 IF P3=B3 THEN P3=1
but it seems slower. IF..THEN slower than the divides. I guess Basic is doing alot of logic for this and waste more cycles. any ideas what to do to remove the divides?
I first thought of doing a lookup table, but that doesnt. In worst case I have to poke or read data statements of shift-opcodes, but are there any other ways?
Thanks. |
|
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Try assembler. :D |
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
What Frantic said... |
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
If you're adamant using BASIC define two-dimensional array A(7,255) with each element containing either 0 or 1 depending on whether the wanted bit (first index) is set in given byte (second index).
That will reduce your logic into
P1 = A(X, PEEK(MEM))
where X is wanted bit, 0..7. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Since you're optimising the cellular automata stuff (obviously) why do you need 0 or 1. Why not 0 or x?
A simple logical-or is then like p1+p2+p3 != 0
A simple logical-and would be p1+p2+p3 == 0
Or use asm... :D |
| |
Perplex
Registered: Feb 2009
Posts: 255 |
You should also use the % suffix on names of variables and arrays that are intended to hold integer values. This should speed up most operations quite a bit. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
great chance to learn asm, the problem is both simple and interesting enough for it at the same time. |
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
I was under the impression that integer variables in BASIC 2.0 are slower than normal ones, because internally they're still represented as floats. Am I wrong? |
| |
WdW
Registered: Jun 2013
Posts: 13 |
yes, they are! so you're right. |
| |
Perplex
Registered: Feb 2009
Posts: 255 |
Really? Oh dear, disregard my suggestion then. Also, what Frantic said. :P |
| |
Tao
Registered: Aug 2002
Posts: 115 |
Quote: I was under the impression that integer variables in BASIC 2.0 are slower than normal ones, because internally they're still represented as floats. Am I wrong?
Seriously? I never knew. And here I've been trying to ensure that new code in C*Base used integers instead of floats o_O |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
Thanks for the comments.
TNT: i made an array of this now.
JackAsser: yes. i should look more into the operators. i made three attempts at an asm version allready, and failed. so, i go to basic code and come back to asm after some time. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:Seriously?
yup. it might still make sense for c*base however, as you probably compile it - and a half decent compiler should make "real" integers from them (basic boss does it at least) |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
482 bytes compiled which is smaller than the asm version and is very slow indeed:
1 G=8192:H=16191:M=53265:POKEM+7,PEEK(M+7)OR8:POKEM,PEEK(M)OR32:FORI=GTOH
2 POKEI,0:NEXT:FORI=1024TO2023:POKEI,1:NEXT:POKEM+15,0:DIMZ%(255,7):FORK=0TO255
3 FORL=0TO7:Z%(K,L)=0:IF((2^L)ANDK)=(2^L)THENZ%(K,L)=1
4 NEXT:NEXT:FORX=0TO31:POKEG+X*8,INT(RND(1)*256):NEXT:S=0:FORY=0TO198:E=S
6 IF(YAND7)=7THENS=S+320
7 V=G+S+((Y+1)AND7):W=G+E+(YAND7):A=-8:B=0:C=0:FORX=1TO318:N=7-((X-1)AND7)
8 U=7-(XAND7):T=7-((X+1)AND7):IFN=7THENA=A+8
9 IFU=7THENB=B+8
10 IFT=7THENC=C+8
11 P=Z%(PEEK(W+A),N):Q=Z%(PEEK(W+B),U):R=Z%(PEEK(W+C),T):I=V+B
12 IF((PANDQ)+R)AND1THENPOKEI,PEEK(I)OR2^U
14 NEXT:NEXT
15 GOTO15
i removed some of the tables in this version to make it shorter. the asm version takes 512b. which i suppose can be reduced a bit further. i dont know if anyone can reach the 256b range. no linear framebuffer is hell. :P
(ref. Chaotic Subsystems) |
| |
Street Tuff
Registered: Feb 2002
Posts: 88 |
hey rudi. i'm down to 332 bytes with something that looks similar to your results from your asm routine. 301 bytes without random initialisation. i think i cant reduce it any more. maybe some bytes here and there. 256 is atleast for me not doable with my approach.
http://www.daupara.de/rule106.rar |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
nice Street Tuff, i think you can get 256b if you process 256 pixels per row instead of 320 like i do in mine? i dont know how your chain works so i dont know how to fix it. |
| |
Fresh
Registered: Jan 2005
Posts: 101 |
This thread tickled me, I couldn't resist writing my own version.
Here it is a different approach and 192 bytes:
https://www.dropbox.com/s/qh2yb562u96qi0s/eca.zip?dl=0 |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
Fresh: cool! that's how it should be done, and runs fast too |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
indeed, but the patterns doesnt seem as chaotic as they shoould be but thats just my gut feeling. |
| |
bugjam
Registered: Apr 2003
Posts: 2589 |
Created an entry for it: ECA.
Cheers! |
| |
Fresh
Registered: Jan 2005
Posts: 101 |
There were room for further (little) improvements: this final version is 7 bytes shorter and a bit faster.
In the same zip there's another binary: in that version the rule is incremented every frame (starting from 106) so you get some kind of a "slideshow".
https://www.dropbox.com/s/0vxogaeacllylsp/eca2.zip?dl=0 |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
Quote: There were room for further (little) improvements: this final version is 7 bytes shorter and a bit faster.
In the same zip there's another binary: in that version the rule is incremented every frame (starting from 106) so you get some kind of a "slideshow".
https://www.dropbox.com/s/0vxogaeacllylsp/eca2.zip?dl=0
cool. is it tricky to do double buffering? also, would it run faster if you don't use random number generator on each iteration but use the same initial condition?
(edit: to get one specific rule in algebraic form use: http://www.wolframalpha.com/input/?i=rule+106+algebraic but wheter or not it can reduce some logic is uncertain. it's also stuck to one rule or fewer rules depending on the algebraic formula. for example rule 90 only needs two inputs: p and q, so r is not needed :P) |
| |
Fresh
Registered: Jan 2005
Posts: 101 |
@Rudy: both features, double buffering and saving the first row, are not that hard to add but I've got something nicer in mind, I'm going to work on in it during the WE.
@Bugjam: I've seen you've added 2 new releases. Thats fine, thanks, but I'll probably post more code in this thread and I wouldn't like to flood csdb with my own WIPs. So, please ask me before adding. Hope you won't mind, there's nothing personal about this.
@Oswald: I'm using SID as random generator, maybe it doesn't produce a nice sequence...
Here it is a shorter (165) and yet a bit faster version.
https://www.dropbox.com/s/xtlerfbxbtwtdy9/eca3.zip?dl=0
I think that this is my limit in terms of size.
Edit:
@Bugjam: Rudi must be credited for the idea in both releases. Thank you. |
| |
Rudi
Account closed
Registered: May 2010
Posts: 125 |
Fresh: nice work. oh, im sure ECA4.zip will come pretty soon :P whats WE? is $d012 bad as PRNG? ive used it a couple of times. but in a loop where accumulator changes. eor $d41b or eor $d012. i cant compile your versions because i dont use kickassembler. i use 64tass. |
| |
bugjam
Registered: Apr 2003
Posts: 2589 |
@Fresh: credits to Rudi added.
No offence taken, won´t add any more. |
| |
Fresh
Registered: Jan 2005
Posts: 101 |
@Bugjam: Thanks.
@Rudi: WE = weekend :). I've just added a tass source in ECA3.zip. You can use $d012 as PRNG in Basic but as soon as you shift to assembly you realize that it's too slow and repetitive: SID noise generator is more reliable. However, if you're interested in the topic, there are some useful and smarter solutions in codebase64. |
