IntyBASIC question

[skywaffle]

Hello,

 

I was just wondering about improving the way I am writing routines in IntyBASIC and had an unusual question.

The question I have is, if I have a statement such as:

 

"IF A > 0 OR B > 0 OR C > 0 OR D > 0 THEN"

 

would there be any performance improvement to rewrite the statement like this?

 

"IF A+B+C+D > 0 THEN"

 

I was not sure if adding variables would be more CPU intensive than using OR

 

Thanks in advance!

[carlsson]

Put both into a test program, compile and compare the assembly code.

 

I'm getting the following output from the first test:

	MVI V1,R0
	CMPI #0,R0
	MVII #-1,R0
	BGT $+3
	INCR R0
	MVI V2,R1
	CMPI #0,R1
	MVII #-1,R1
	BGT $+3
	INCR R1
	COMR R1
	ANDR R1,R0
	COMR R1
	XORR R1,R0
	MVI V3,R1
	CMPI #0,R1
	MVII #-1,R1
	BGT $+3
	INCR R1
	COMR R1
	ANDR R1,R0
	COMR R1
	XORR R1,R0
	MVI V4,R1
	CMPI #0,R1
	MVII #-1,R1
	BGT $+3
	INCR R1
	COMR R1
	ANDR R1,R0
	COMR R1
	XORR R1,R0
	BEQ T1

compared to the following output from the second test:

	MVI V1,R0
	ADD V2,R0
	ADD V3,R0
	ADD V4,R0
	CMPI #0,R0
	BLE T2

Obviously your variables must be unsigned, if either of A, B, C or D would be < 0 the second test would yield odd results.

 

Edit: That is assuming ADD the content of a memory address to a register doesn't take a lifetime to complete.

Edited August 15, 2018 by carlsson

[+DZ-Jay]

Hello,

 

I was just wondering about improving the way I am writing routines in IntyBASIC and had an unusual question.

The question I have is, if I have a statement such as:

 

"IF A > 0 OR B > 0 OR C > 0 OR D > 0 THEN"

 

would there be any performance improvement to rewrite the statement like this?

 

"IF A+B+C+D > 0 THEN"

 

I was not sure if adding variables would be more CPU intensive than using OR

 

Thanks in advance!

 

Well, the first thing you have to know is that the Intellivision's CPU does not offer an "OR" operation, so it has to be implemented in code in terms of other primitives. That by itself incurs a performance penalty.

 

That means that it would be preferable always if you can avoid using OR altogether.

 

That said, I do not know to what extent IntyBASIC will optimize that expression during compilation, so I can't comment on whether it will actually make a difference; although I suspect it will.

 

There is one last thing I'd like to comment on, and it is something I have mentioned before. In my experience so far looking at intyBASIC programmers' code, it occurs to me that processing of expressions such as yours is but a little tiny drop in the ocean of performance-eating operations and algorithms in IntyBASIC programs.

 

That is not to say that IntyBASIC is slow, but that you are better off optimizing in other areas first, if performance is an actual manifested problem in your program at all. Most of the time, it is not really a problem to solve.

 

In other words, I personally would only use your second expression if you are actually encountering some performance issue and have optimized the most costly parts already. Maintaining the intuitive clarity that the "OR" expression provides is more valuable than spurious "premature optimizations."

 

I am revising my last statement in light of seeing the actual generated code. The advantage is significant, so there's no real reason to keep those "OR" operators.

 

Reading/adding from memory (in "direct" mode) costs only 10 cycles; while the combination of INCR, COMR, ANDR, COMR, XORR -- at 6 cycles apiece -- takes 30 cycles per expression term. That's quite an expense!

 

dZ.

[skywaffle]

Thank you for the quick replies. Initially I was dealing with performance issues, but after following some advice from Nanochess, I was able to get things working much more smoothly by changing statements like:

 

IF A > 0 AND B = 4 AND C <= 15 THEN

 

to statements like:

 

IF A > 0 THEN IF B = 4 THEN IF C <= 15 THEN

 

I have also tried eliminating unnecessary addition on things like sprites, such as HIT + VISIBLE to $0300. I am sure these changes offer little benefit, but with more logic to add to the program, every bit of savings might help.

[+DZ-Jay]

Thank you for the quick replies. Initially I was dealing with performance issues, but after following some advice from Nanochess, I was able to get things working much more smoothly by changing statements like:

 

IF A > 0 AND B = 4 AND C <= 15 THEN

 

to statements like:

 

IF A > 0 THEN IF B = 4 THEN IF C <= 15 THEN

 

I have also tried eliminating unnecessary addition on things like sprites, such as HIT + VISIBLE to $0300. I am sure these changes offer little benefit, but with more logic to add to the program, every bit of savings might help.

Wait, why would HIT + VISIBLE be different from $0300??? Immediate values in expressions should result in an evaluated expression. If not, there is something wrong with the compiler.

 

Forcing everyone to use "magic numbers" instead of symbolic constants seems rather onerous.

 

We put a lot of work in getting the constants in "Constants.bas" together. I understand that nanochess has not given much emphasis to the ease of use of the IntyBASIC SDK (it wasn't even mentioned in his book), but is he saying that the "Constants.bas" is useless now?

 

If the file is not going to be endorsed and people are actively discouraged from using it, then we shouldn't bother maintaining it.

 

dZ.

[skywaffle]

I would have assumed that it would be having to add those, just as it would in a BASIC interpreter. I should be looking at the assembly code as Carlsson has suggested to see if there is or not and not make assumptions, but was just describing what I had previously done before I had asked the first question.

[skywaffle]

Sorry for my ignorance on this. I still use Constants.BAS, and probably would not have managed to get far in IntyBASIC without it. Nanochess made a suggestion of optimizing my code to improve performance because of all the comparison statements that I use. I just thought that the addition of things like HIT + VISIBLE might have been less efficient than $0300.

[+nanochess]

IntyBASIC optimizes adding, substraction, multiplication and division by constant.

 

There's no gain in putting the optimized constant because the compiler does it in the output. This also helps to use meaningful names.

 

Give a look to the generated code. You can search for your text as your source code is intermixed with generated assembler code.

[artrag]

Oscar, from the code generated above, why not removing the cmpi #0,Rx when the previous opcode is already setting the Z flag (and is testing Rx naturally)?

Edited August 15, 2018 by artrag

[+nanochess]

Oscar, from the code generated above, why not removing the cmpi #0,Rx when the previous opcode is already setting the Z flag (and is testing Rx naturally)?

Because it checks for BLE, not BEQ/BNE and I haven't checked the outcome of flags in this case.

[artrag]

But it would be equal to BNE, wouldn't it?

[intvnut]

Because it checks for BLE, not BEQ/BNE and I haven't checked the outcome of flags in this case.

 

But it would be equal to BNE, wouldn't it?

 

If the previous instruction is an ADD, as in this example, the CMPI #0 is indeed redundant. You could use BLE there without the CMPI #0. That would require the code generator to know that the last instruction issued generated the exact flags you needed, though. If the previous instruction were simply a MVI (as you might have with "FOO > 0"), then you do need some sort of test there.

 

 

Edit: That is assuming ADD the content of a memory address to a register doesn't take a lifetime to complete.

 

Fortunately, ADD mem, Rx takes exactly as long as MVI mem, Rx. The Intellivision doesn't have wait states, so that's also always 10 cycles.

 

 

For this one:

 

Thank you for the quick replies. Initially I was dealing with performance issues, but after following some advice from Nanochess, I was able to get things working much more smoothly by changing statements like:

 

IF A > 0 AND B = 4 AND C <= 15 THEN

 

to statements like:

 

IF A > 0 THEN IF B = 4 THEN IF C <= 15 THEN

 

I have also tried eliminating unnecessary addition on things like sprites, such as HIT + VISIBLE to $0300. I am sure these changes offer little benefit, but with more logic to add to the program, every bit of savings might help.

 

It seems like IntyBASIC could possibly benefit from some short-circuit evaluation for AND and OR inside of an IF? Nesting IF-THEN statements like this does make the code harder to follow.

 

That said, you probably want some new operators that are explicitly short-circuit, just in case folks are relying on side effects somehow. (Most IntyBASIC statements are side-effect free, but assembly functions aren't guaranteed to be.)

 

 

 

I echo nanochess' suggestion to look at the generated code. IntyBASIC interlists the original BASIC code with the code that gets generated, so it's relatively easy to figure out what got generated for each line of input. I often write short test cases to see what a few lines of code might generate, just to see what plays best with IntyBASIC's code generator.

 

IntyBASIC does try to cache some values in registers, so the order that you write certain expressions can have a minor, but cumulative impact. Consider these two examples:

.

' Example 1
#A = #B + #A
#A = #C + #A

' Example 2
#A = #A + #B
#A = #A + #C

.

The code generated for Example 1 looks like this:

.

    ;[1] ' Example 1
    SRCFILE "o.bas",1
    ;[2] #A = #B + #A
    SRCFILE "o.bas",2
    MVI V2,R0
    ADD V1,R0
    MVO R0,V1
    ;[3] #A = #C + #A
    SRCFILE "o.bas",3
    MVI V3,R0
    ADD V1,R0
    MVO R0,V1

.

The code generated for Example 2, though, is one instruction shorter:

.

    ;[1] ' Example 2
    SRCFILE "o.bas",1
    ;[2] #A = #A + #B
    SRCFILE "o.bas",2
    MVI V1,R0
    ADD V2,R0
    MVO R0,V1
    ;[3] #A = #A + #C
    SRCFILE "o.bas",3
    ADD V3,R0
    MVO R0,V1

.

Notice that the second addition was able to reuse the value left in R0 from the previous expression. Most of the time, the cost is minor and can be safely ignored. But, when you're in a loop, you multiply that cost, so it can be worth considering.

 

As far as CONSTANTS.BAS goes, do keep using expressions such as HIT + VISIBLE. IntyBASIC does fold that down to a single constant, and it's more readable than $0300. Also, declaring CONST values for commonly used constants can make your program much more readable, IMHO.