25 February 2018, 23:22 | #1 |
Registered User
Join Date: Jul 2017
Location: San Jose
Posts: 652
|
Whats wrong with this line of assembly?
NF_SUBSECTOR = $8000 results in: /home/matze/amigatoolchain/amiga-gcc-out/bin/vasmm68k_mot -Fhunk -phxass -warncomm -nosym -ldots -spaces -m68030 -m68882 -I/home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/sys-include -I/home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/ndk/include amigaasm/r_engine.asm -o r_engine.o I believe the ~ somehow turns the value into a 32bit value... but how can I convey to vasm to just use it as word sized? |
25 February 2018, 23:37 | #2 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
Nf_subsector = -$8000
EDIT: for some reason the editor convert NF_SUBSECTOR to Nf_subsector... why?! EDIT2: verbose mode I think it's due to the fact that instructions default to .w operations So in a 16 bit two's complement logic $8000 cannot exist.. -$8000 yes Last edited by ross; 26 February 2018 at 00:11. Reason: for some reason the editor converted NF_SUBSECTOR to Nf_subsector... |
25 February 2018, 23:37 | #3 |
Registered User
Join Date: Dec 2010
Location: Athens/Greece
Age: 53
Posts: 719
|
try and #~NF_SUBSECTOR&$FFFF,d0
|
25 February 2018, 23:42 | #4 |
Going nowhere
Join Date: Oct 2001
Location: United Kingdom
Age: 50
Posts: 8,986
|
Try adjusting the value $8000 to $7fff
|
26 February 2018, 03:19 | #5 |
Registered User
Join Date: Jul 2017
Location: San Jose
Posts: 652
|
Both Alkis and Galahad's solutions work, though I chose Alki's in the end (to stick with a named symbol rather than a magic number)
What I don't understand: why bitwise negating a 16bit number does not result in a 16bit number - is this a bug in vasm maybe? |
26 February 2018, 03:48 | #6 | |
Registered User
Join Date: Apr 2005
Location: digital hell, Germany, after 1984, but worse
Posts: 3,365
|
Quote:
NF_SUBSECTOR = $8000 = $00008000 and #~NF_SUBSECTOR,d0 = and #~$00008000,d0 = and #$FFFF7FFF,d0 |
|
26 February 2018, 03:54 | #7 |
Registered User
Join Date: Jul 2017
Location: San Jose
Posts: 652
|
I thought the 'and' without .w defaults to .w - no?
Adding .w yields the same error message. If its an error in the declaration of NF_SUBSECTOR, how do I change it so it would become a 16bit number? |
26 February 2018, 03:58 | #8 |
Registered User
Join Date: Apr 2005
Location: digital hell, Germany, after 1984, but worse
Posts: 3,365
|
AND.W won't help because it will not delete the upper 16 bits, of course.
|
26 February 2018, 04:01 | #9 |
Registered User
Join Date: Jul 2017
Location: San Jose
Posts: 652
|
So the question remains: how to declare less-than-32bit symbols then?
|
26 February 2018, 04:07 | #10 |
Registered User
Join Date: Apr 2005
Location: digital hell, Germany, after 1984, but worse
Posts: 3,365
|
No, the problem is that you cannot filter a longword reliable in D0 with only 16 bits. You have to expand it to 32 bits as shown by alkis.
In case that you want to process the contents of D0 later only as a word in your code, you may have to ask Frank Wille why this error message appears. I'm not a user of VASM, I still prefer the good old PhxAss, but never had to fight with such a problem yet (because anything similar newer existed in my code). Did you already try NF_SUBSECTOR DC.W $8000 but that's not a preprocessor declaration maybe NF_SUBSECTOR = $8000.w ???? Last edited by PeterK; 26 February 2018 at 04:47. |
26 February 2018, 04:59 | #11 | |
Registered User
Join Date: Jul 2017
Location: San Jose
Posts: 652
|
Quote:
Alkis method is truncating back to 16bit, not expanding to 32bit. I think what happens is that NF_SUBSECTOR is treated as 32bit constant (that just happens to fit into 16bit). When the ~ operator is applied, the result is $FFFF7FFF (as you showed), which doesn't fit into 16bits anymore. Anyways, thanks for your input... its working now. This thread is already way too long for a single assembly line ;-( |
|
26 February 2018, 05:16 | #12 | |
Registered User
Join Date: Apr 2005
Location: digital hell, Germany, after 1984, but worse
Posts: 3,365
|
Quote:
Best you could do is to ask Frank Wille (phx) Cheers ... Peter |
|
26 February 2018, 08:31 | #13 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
Operators in vasm, as well as in phxass, use longwords regardless of instruction size. I guess most assemblers will do the same.
This behaviour is perfectly normal. You can use exclusive or to perform the "~" operation on a word (this is for phxass, i don't know if vasm uses the same character for eor) : Code:
NF_SUBSECTOR = $8000 and.w #NF_SUBSECTOR^$ffff,d0 Code:
NB_SUBSECTOR = 15 bclr #NB_SUBSECTOR,d0 |
26 February 2018, 13:06 | #14 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
But the problem lies in the fact that you use the constant NF_SUBSECTOR both as 16 and 32 bit?
Because otherwise no problems arose. If you define as -$8000 the value is the same both 16 or 32 bit: $FFFF8000 or $8000, sign extended And if you use and.w #~NF_SUBSECTOR,d0or and.l #~NF_SUBSECTOR,d0or and #~NF_SUBSECTOR,d0result is one: and.x #$7fff,d0, that is the requested operation (logically for .w upper bits are untouched). So, even if assembler default to 32bit, result is correct. What's wrong with this? |
26 February 2018, 13:34 | #15 |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,863
|
|
26 February 2018, 13:37 | #16 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,323
|
|
26 February 2018, 13:58 | #17 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
|
26 February 2018, 16:57 | #18 | |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,496
|
Quote:
So equates are always stored as 32 bit values. And eval_expression() always returns $ffff7fff for ~$8000. Then the AND.W instruction checks its immediate operand, which doesn't match its current operation size... Yes, I think all assemblers work that way. Otherwise I have to fix it. |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Hmmm, wonder whats wrong with these guys ? | HnieX | Amiga scene | 0 | 19 January 2012 18:00 |
Whats Wrong ?! | SWOS | support.Games | 23 | 10 January 2006 00:36 |
A600HD whats wrong with it? | chaoticjelly | support.Hardware | 2 | 27 June 2005 19:23 |
What happened to: The Assembly Line | TazDevil76 | Retrogaming General Discussion | 3 | 19 January 2005 00:31 |
Whats wrong with this mod | Ian | support.Demos | 7 | 04 December 2001 17:05 |
|
|