Excellent answer ! Even some information you exposed is known to me, other points are new or totally buried and forgotten.
The answer I was looking for is here: "Years ago, each hardware guy was creating their own processor. And they created their own "symbols table" to be shown in screen/printer. " Your explanation here, fit perfectly with what I find and also microchip explanation.
I know I am presenting a PIC asm code here, and I apologize for it, posting it here, but it is the entire context very well summarized in it.
I did test these things for around 2 days, coming back again numerous times, with breaks. Hammering is the best word.
Scroll down in this code to see the final answer from Microchip forum, AFTER I reach my conclusions and finished my tests.
I already resolved the problem and find a solution: to not use that 0b... opcode.
Their answer was not was I expected ! That's why on internet you will find so many not working codes for pic's assemblers and hilevel as well.
This was a very illuminating experience. Im very glad I get the context on everything.
What I was expecting/believing originally as an answer from both parts (you masm, and them microchip), was different meanings in code and specific usage of these opcodes. But it turned out to be completely different usage and context than what I believed.
- I wonder if its the same situation for masm as well, where different opcodes are mingled on the internet, and they come from different asm languages with different sintaxes and naming? You've already presented me the uasm console asm compiler, but in my very short usage of it, I didnt spot any diferences from masm (not that I use it very long as well) haha. Is my belief that uasm is like a mask over masm. I am way too curious? Haha.
Also, I find opcodes that are from masm or win asm, written for pic codes. I find 1 example in all my research, and seeing you mentioning the 00001000b opcode now, it pop the "aha". I am inclined to believe(well, for a long time actually) these code samples on internet, a large majority of them are intentionally screwed to not be able to use them staying comfortable at home.
From this perspective, this part was the hardest for me, the greatest impediment, when I was learning pic asm back in time. Now as well, I can not differentiate between that guy opcodes or symbols as you put it, or the other guy. Especially in the beginning of learning with a minimal experience. I like things to be black and white. Who doesn't?
Oh,oh, also I play with the binary code and I figure out, also I asked microchip and they clarified this thing for me: there are bits in their registers, that are not implemented ! So basically you can write whatever to those bits, it will not matter. So in other words, a register with 6 bits in it, is actually a 8bits but with 2 bits unimplemented. I didn't ask yet, but I will, about 16bits register, but my big impression its 4 bits are not implemented, and the register appear as 12bits, for our delicious confusion.If you pay attention in my code, I am writing the full 8 bits in the opcode: for ex: b'00001000' has 8bits in it, but everywhere else, on every tutorial, is written as 4bits in this case: b'1000' or the large majority of encountered codes as 6 bits. And it works fine with how I am writing it as 8 bits !!! No problem.
So...
my test code is like this:
include "p12f508.inc"
__config _MCLRE_OFF & _CP_OFF & _WDT_OFF & _IntRC_OSC
org 0
clrf GPIO
;0b... is accepted by asm compiler but is a wrong command !!!
;I got a ton of errors using 0b....
;MOVLW 0b00111111
;MOVLW 0b00001000
;b'...' command is the only CORRECT command to use
MOVLW b'00111111'
;MOVLW b'00001000'
tris GPIO
movlw 0xDF
option
movlw 0xFF
movwf OSCCAL
Start
;MOVLW 0b111110
MOVLW b'111111'
MOVWF GPIO
END
;Microcip Clarifications:
;The b'00001000' is used by the MPASM assembler, and
;the 0b00001000 prefix is used by the PIC-AS assembler (and XC8 C compiler).
;Microcip forum explanation:
;radix dec
;Unfortunately the default radix of MPASM is hexadecimal;
;that is, unprefixed numbers are hexadecimal numbers.
;So, for example, 0bad is hexadecimal number 0x0BAD (0b00001000 is actually 0x0B00001000).
;That is the reason why I always set the radix to decimal with
;list r=dec or
;radix dec
;Setting the default radix to DEC also avoids the stupid dot syntax for decimal numbers.
;00000100B is documentated in XC8 Compiler pdf. ;It is read as a backward label (temp) if lowercase.
;That is the binary syntax for the ASPIC and ASPIC18 assemblers.
;in Conclusion: learn what to use and what NOT to use.