FAQ  •  Register  •  Login

New features (XOR, bitwise operators)

<<

britlion

Posts: 722

Joined: Mon Apr 27, 2009 7:26 pm

Location: Slough, Berkshire, UK

Post Fri Jul 16, 2010 8:40 am

New features (XOR, bitwise operators)

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

Site Admin

Posts: 1271

Joined: Wed Nov 01, 2006 6:18 pm

Location: Santa Cruz de Tenerife, Spain

Post Fri Jul 16, 2010 9:05 am

Re: Wrong PEEKed value from @label

britlion wrote: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).
Britlion wrote: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

britlion wrote: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.
britlion wrote: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

Posts: 567

Joined: Fri Feb 13, 2009 3:11 pm

Location: Vienna, Austria

Post Fri Jul 16, 2010 1:35 pm

Re: Wrong PEEKed value from @label

I redownloaded it. It works now fine, but is the old version Build 1603g (newer version not available from http://www.boriel.com/wiki/en/index.php ... IC:Archive yet) and so it does not accept XOR operator or ALIGN.
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
<<

britlion

Posts: 722

Joined: Mon Apr 27, 2009 7:26 pm

Location: Slough, Berkshire, UK

Post Fri Jul 16, 2010 1:43 pm

Re: Wrong PEEKed value from @label

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

Posts: 722

Joined: Mon Apr 27, 2009 7:26 pm

Location: Slough, Berkshire, UK

Post Fri Jul 16, 2010 2:07 pm

Re: Wrong PEEKed value from @label

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

boriel

Site Admin

Posts: 1271

Joined: Wed Nov 01, 2006 6:18 pm

Location: Santa Cruz de Tenerife, Spain

Post Fri Jul 16, 2010 6:07 pm

Re: Wrong PEEKed value from @label

britlion wrote: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

Posts: 722

Joined: Mon Apr 27, 2009 7:26 pm

Location: Slough, Berkshire, UK

Post Fri Jul 16, 2010 8:17 pm

Re: Wrong PEEKed value from @label

boriel wrote:
britlion wrote: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

Site Admin

Posts: 1271

Joined: Wed Nov 01, 2006 6:18 pm

Location: Santa Cruz de Tenerife, Spain

Post Sat Jul 17, 2010 1:15 am

Re: Wrong PEEKed value from @label

LCD wrote:I re-downloaded it. It works now fine, but is the old version Build 1603g (newer version not available from http://www.boriel.com/wiki/en/index.php ... IC:Archive 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

Posts: 567

Joined: Fri Feb 13, 2009 3:11 pm

Location: Vienna, Austria

Post Sat Jul 17, 2010 10:01 pm

Re: Wrong PEEKed value from @label

boriel wrote:
LCD wrote:I re-downloaded it. It works now fine, but is the old version Build 1603g (newer version not available from http://www.boriel.com/wiki/en/index.php ... IC:Archive 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.
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!

Return to Wishlist

Who is online

Users browsing this forum: No registered users and 1 guest

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by Vjacheslav Trushkin for Free Forums/DivisionCore.

phpBB SEO