New features (XOR, bitwise operators)

[britlion]

Was working for me too.

Boriel, I assume that XOR is used like AND and OR and NOT ?

How about align? I assume it moves code up to the next 256 byte block (staggeringly useful stuff, that).
What's the syntax and working for that?
Does it just leave a blank space?
(Can we work out how much?)
Do we automatically get an @label to reference the point - or do we start the block after the align with one?
How do we work out what page it is? @label/256?

[boriel]

Was working for me too.

Boriel, I assume that XOR is used like AND and OR and NOT ?

XOR is the LOGICAL (not bitwise) one. Works like AND, OR, NOT. It's rarely seldom used (I've only seen it implemented in XBASIC). Basically, it checks if only one of the two given conditions is true. For more than two conditions, you should use parenthesis, etc...
Instead of:

Code:

IF X > 5 AND NOT (y < 10) OR NOT (X > 5) AND y < 10 THEN
   ...
END IF

You can write now:

Code:

IF X > 5  XOR y < 10 THEN
   ...
END IF

Which not only is shorter to write, but also faster to run (and take less memory).

How about align? I assume it moves code up to the next 256 byte block (staggeringly useful stuff, that).
What's the syntax and working for that?

The syntax is ALIGN n (N an expression, mostly an integer number).

Code:

;; Aligns the code to start at 256 * n
;; (0, 256, 512, ...)
ALIGN 256

Does it just leave a blank space?
(Can we work out how much?)

It leaves "undefined" (usually 0-filled) bytes. The amount of bytes wasted depends on your code position. It simply fills the space until your next code is aligned. This is useful for some speed up optimizations (mostly in x86 architectures). In Z80, for drawing sprites, there's a trick (apenao is using it for his sprites routine). Aligning the code in a 256 boundary (might waste up to 255 bytes!), can speed up read/write memory transfers, since every INC HL and INC DE could be replaced by INC L and INC E respectively which are some t-states faster.

Do we automatically get an @label to reference the point - or do we start the block after the align with one?
How do we work out what page it is? @label/256?

Just use a label following the ALIGN N sentence. This label will be a the beginning of your aligned block. You can also use that label in numerical expressions such as MYLABEL / 256.

[LCD]

I redownloaded it. It works now fine, but is the old version Build 1603g (newer version not available from <!-- m --><a class="postlink" href="http://www.boriel.com/wiki/en/index.php/ZX_BASIC:Archive">http://www.boriel.com/wiki/en/index.php ... IC:Archive</a><!-- m --> yet) and so it does not accept XOR operator or ALIGN.

[britlion]

Okay, XOR is not bitwise, and ALIGN does more or less what I expected (Though I didn't expect a parameter!) I think it's almost always going to be used as ALIGN 256. Just maybe used as ALIGN 16384 for pushing stuff up into the top 16K of memory for 128K programming.

There are several clever cases for aligning data - tables for example, often need to be aligned. Sprite rotation tables, critically so.

[britlion]

Wiki has been updated for XOR and ALIGN. Please check to see if it's correct!

[boriel]

Okay, XOR is not bitwise, and ALIGN does more or less what I expected (Though I didn't expect a parameter!) I think it's almost always going to be used as ALIGN 256. Just maybe used as ALIGN 16384 for pushing stuff up into the top 16K of memory for 128K programming.

There are several clever cases for aligning data - tables for example, often need to be aligned. Sprite rotation tables, critically so.

BITWISE operator we agreed (if I recall correctly) to be prefixed with "b" son:
bXOR, bAND, bOR, bNOT will be such operators, and their respective symbol equivalence ~ (bXor), & [bAnd], | (bOr), ! (bNot). Well, maybe there's a better symbol for not.

[britlion]

Okay, XOR is not bitwise, and ALIGN does more or less what I expected (Though I didn't expect a parameter!) I think it's almost always going to be used as ALIGN 256. Just maybe used as ALIGN 16384 for pushing stuff up into the top 16K of memory for 128K programming.

There are several clever cases for aligning data - tables for example, often need to be aligned. Sprite rotation tables, critically so.

BITWISE operator we agreed (if I recall correctly) to be prefixed with "b" so:
bXOR, bAND, bOR, bNOT will be such operators, and their respective symbol equivalence ~ (bXor), & [bAnd], | (bOr), ! (bNot). Well, maybe there's a better symbol for not.

Absolutely - a b prefix makes it clearer (and we can hardly use AND/OR/NOT/XOR - since they are used for boolean logic!). Sorry, wasn't meaning to suggest I expect XOR to work that way, was just restating to show I'd got it. Hopefully the new wiki entries read okay on that.

[boriel]

I re-downloaded it. It works now fine, but is the old version Build 1603g (newer version not available from <!-- m --><a class="postlink" href="http://www.boriel.com/wiki/en/index.php/ZX_BASIC:Archive">http://www.boriel.com/wiki/en/index.php ... IC:Archive</a><!-- m --> yet) and so it does not accept XOR operator or ALIGN.

You have re-downloaded the same version, because I've forgot to upload the latest one. This means there was no bug related to .asm inclusion files and probably your installation was corrupted: I couldn't reproduce such bug. Please download it again, 1.2.6-1603h is ready.

[LCD]

I re-downloaded it. It works now fine, but is the old version Build 1603g (newer version not available from <!-- m --><a class="postlink" href="http://www.boriel.com/wiki/en/index.php/ZX_BASIC:Archive">http://www.boriel.com/wiki/en/index.php ... IC:Archive</a><!-- m --> yet) and so it does not accept XOR operator or ALIGN.

You have re-downloaded the same version, because I've forgot to upload the latest one. This means there was no bug related to .asm inclusion files and probably your installation was corrupted: I couldn't reproduce such bug. Please download it again, 1.2.6-1603h is ready.

Yes, I know..
Thanks for uploading the new version. I just downloaded it, looks like it is working as expected.