Author Topic: Axe Parser (Read 552112 times)

Michael_Lee · « **Reply #1590 on:** December 21, 2010, 03:24:25 pm »

Sweet, thanks!

Deep Toaster · « **Reply #1591 on:** December 21, 2010, 08:02:21 pm »

And remember to put the least commonly true statement on top to make it eve faster

Michael_Lee · « **Reply #1592 on:** December 23, 2010, 01:01:05 pm »

Follow-up question to this: http://ourl.ca/4050/155915

What if both A and B had a high chance of being true at the same time? Then would

Code: [Select]

If A
  If B
    Do stuff
  End
End

still be the fastest way to evaluate it?

calcdude84se · « **Reply #1593 on:** December 23, 2010, 01:05:36 pm »

Something to note about using "A and B" is that, for example, if A is 2 and B is one, then "A and B" evaluates to 0. (This is no concern if A and B are never anything other than 1.) You have to use "(A!=0) and (B!=0)", where "!=" is the not equal to sign, to get around this.

Michael_Lee · « **Reply #1594 on:** December 23, 2010, 01:09:34 pm »

Yeah, I remember that. That was one of the more inexplicable 'bugs' I had encountered while making my minesweeper game.

But nevertheless:

Code: [Select]

If A
  If B
    Do stuff
  End
End

or...

If A!=0 and (B!=0)
  Do stuff
End

Which is faster, given A and B are usually both true?

Runer112 · « **Reply #1595 on:** December 23, 2010, 01:12:00 pm »

Keeping in mind what calcdude84se pointed out about A and B, if either A or B will sometimes be non-boolean values (anything besides 0 and 1), you want to use the two separate if statements. If they will always be booleans, however, compare the following two blocks of code:

Code: [Select]

If A
  If B
    Do stuff
  End
End

A is false: 34 t-states
A is true: 68 t-states

Code: [Select]

If A and B
  Do stuff
End

66 t-states

The second one is only faster if A will be true at least 16/17 of the time.

Michael_Lee · « **Reply #1596 on:** December 23, 2010, 01:14:06 pm »

Erm, what is a 't-state', and how exactly did you arrive by those numbers?

calcdude84se · « **Reply #1597 on:** December 23, 2010, 01:15:24 pm »

It has to deal with the underlying machine code that Axe produces.
He looked at the disassembled code

(There are tables for how many t-states each opcode takes)

Happybobjr · « **Reply #1598 on:** December 23, 2010, 01:27:17 pm »

where would one find these tables?

calcdude84se · « **Reply #1599 on:** December 23, 2010, 01:31:13 pm »

There is a plethora of information on the z80 processor in general at z80.info
In addition, in the instruction set reference in the 28Days tutorial.

Builderboy · « **Reply #1600 on:** December 23, 2010, 02:18:33 pm »

Quote from: Runer112 on December 23, 2010, 01:12:00 pm

Keeping in mind what calcdude84se pointed out about A and B, if either A or B will sometimes be non-boolean values (anything besides 0 and 1), you want to use the two separate if statements. If they will always be booleans, however, compare the following two blocks of code:

Code: [Select]
If A If B Do stuff End End
A is false: 34 t-states
A is true: 68 t-states

Code: [Select]
If A and B Do stuff End
66 t-states

The second one is only faster if A will be true at least 16/17 of the time.

Thats excellent data! So what that means is that even if A is true 94% of the time, its still worth it to make the change to two if statements

So as a general rule, the best thing to do is to use two different If statements if you are going for absolute speed. Unless A is only false like once in every 9000th cycle

lookitsan00b · « **Reply #1601 on:** December 23, 2010, 02:57:46 pm »

Quote from: Builderboy on December 23, 2010, 02:18:33 pm

Quote from: Runer112 on December 23, 2010, 01:12:00 pm
Keeping in mind what calcdude84se pointed out about A and B, if either A or B will sometimes be non-boolean values (anything besides 0 and 1), you want to use the two separate if statements. If they will always be booleans, however, compare the following two blocks of code:

Code: [Select]
If A If B Do stuff End End
A is false: 34 t-states
A is true: 68 t-states

Code: [Select]
If A and B Do stuff End
66 t-states

The second one is only faster if A will be true at least 16/17 of the time.

Thats excellent data! So what that means is that even if A is true 94% of the time, its still worth it to make the change to two if statements So as a general rule, the best thing to do is to use two different If statements if you are going for absolute speed. Unless A is only false like once in every 9000th cycle

And if A is only false once in every 9000th cycle, you could probably do

Code: [Select]

:If B
:  If A
:    do stuff
:  End
:End

of course that requires the order to be interchangeable

Quigibo · « **Reply #1602 on:** December 23, 2010, 03:38:43 pm »

The statistics would be different if you assume that A and B are non-Boolean. In that case you have extra clock cycles for the not equals zero operations which might actually make it always faster to do the 2 separate statements regardless of probability. But then again, realistically in programs, there is likely to be a mix of operations so I would include in that calculation.

Code: [Select]

If A__op__
  If B__op__
    Do stuff
  End
End

Code: [Select]

If A__op__ and (B__op__)
  Do stuff
End

In this case, assuming the previous numbers were correct, there is a difference of
* A is false: 34 t-states + ops
* A is true: 68 t-states + ops

Against:
* Always: 87 t-states + ops

So you should always short circuit if you're looking for a speed optimization (assuming non-Boolean), but the second is smaller I think.

DJ Omnimaga · « **Reply #1603 on:** December 26, 2010, 01:13:22 am »

Nice trick guys

Quigibo · « **Reply #1604 on:** December 26, 2010, 05:16:53 am »

Yup, so the last of the betas is out (hopefully). Now is the time to catch those bugs so 1.0.0 can be as bug free as possible. I would also like to get a small group to test pre-releases so that I can be more confident in the stability. The only requirement is that you have at least one very large file and a variety of programs to test it on. I am also interested in an assembly programmer who wants to get a head start writing an Axiom so I can have another example to play with in addition to my mode 7 Axiom. Examples of possible Axiom projects: CalcNet, Raycaster, DCS GUI interface, Fast Math Library, or anything else you can think of.

I'll be gone for a few days, but I'll start picking volunteers when I get back. There will probably be a bias to more experienced Axe programmers since I only need a few.

Author Topic: Axe Parser (Read 552112 times)

Michael_Lee

Re: Axe Parser

Deep Toaster

Re: Axe Parser

Michael_Lee

Re: Axe Parser

calcdude84se

Re: Axe Parser

Michael_Lee

Re: Axe Parser

Runer112

Re: Axe Parser

Michael_Lee

Re: Axe Parser

calcdude84se

Re: Axe Parser

Happybobjr

Re: Axe Parser

calcdude84se

Re: Axe Parser

Builderboy

Re: Axe Parser

lookitsan00b

Re: Axe Parser

Quigibo

Re: Axe Parser

DJ Omnimaga

Re: Axe Parser

Quigibo

Re: Axe Parser