Electronics > Microcontrollers

Why do people not like Microchip?

<< < (42/57) > >>

MIS42N:
Northguy has the same solution as piclist http://www.piclist.com/techref/microchip/math/radix/a2b-2h8b-pf.htm which, if I had found it earlier would have saved a bit of time. It is a more logical approach using twos complement addition to do subtraction (PIC doesn't have a subtract literal from register, so the equivalent is add a twos complement). In essence, it converts the ascii 4k to ascii 3k+9, then removes the 3s in the last line. I was not so smart. Knowing the ascii 4k had to have 9 added, I added it to every character (the combination of 0x55 and the 4 in 4k) I then adjusted the 3k numbers which now were 3k+9 TO 4k by adding another 7. The end result is the same, the cycles are the same, the execution time is the same.

T3sl4co1l:
Speaking from experience with avr-gcc at least, the compiler can recognize a swap -- even with optimization sadly, GCC will still mask the result if you do e.g. (x >> 4) & 0x0f, even if you don't use the high nibble in subsequent operations; however, using x >> 4 | x << 4 or something like that, will properly elucidate the SWAP instruction.  So it's sometimes worthwhile to add both terms to the expression, even if you aren't using one of the results.

Possibly the same is true of PIC compilers.

Tim

NorthGuy:

--- Quote from: MIS42N on October 07, 2021, 10:55:45 pm ---Northguy has the same solution as piclist http://www.piclist.com/techref/microchip/math/radix/a2b-2h8b-pf.htm which, if I had found it earlier would have saved a bit of time. It is a more logical approach using twos complement addition to do subtraction (PIC doesn't have a subtract literal from register, so the equivalent is add a twos complement). In essence, it converts the ascii 4k to ascii 3k+9, then removes the 3s in the last line. I was not so smart. Knowing the ascii 4k had to have 9 added, I added it to every character (the combination of 0x55 and the 4 in 4k) I then adjusted the 3k numbers which now were 3k+9 TO 4k by adding another 7. The end result is the same, the cycles are the same, the execution time is the same.

--- End quote ---

That's the same method as yours. I actually tried to explain how your method can be derived, but it came out with reverse coefficients.

0xcd + 0x8f + 0xfd = 0x55 - here's your 0x55 for the case where both chars are letters
0x55 + 0x71 + 0x07 = 0xcd - here's 0xcd from my post for the case where both chars are digits

AaronD:

--- Quote from: NorthGuy on October 07, 2021, 09:52:00 pm ---...the creators of ASCII were dumb and didn't do it this way...

--- End quote ---

I wouldn't quite say that.  They were just optimizing string functions.  See how capitals and lowercase line up nicely with each other?  It took some padding to do that, so they used the punctuation characters for the padding, and followed some patterns for those too.  And it still doesn't take much effort at all to convert two ASCII hex characters to a byte, as shown in the previous few posts.

I think it would only add one instruction to handle both upper and lower case:  When you know it's a letter, force one bit to make it known which case it is, then add the appropriate offset for that known case.  For comparison, bounds-checking everything would probably double the code size.


Also interesting are the control characters that were used originally to control a teletype, or "remote-controlled dumb typewriter".  We hardly use any of them now:

* carriage ("print head") return
* line (paper) feed
* horizontal tab (there's a now-barely-used v-tab too; both of these together make tables somewhat easier)
* escape
* backspace
* deletebut it's interesting to see that the rest of them are still part of the modern standard.

T3sl4co1l:
Don't forget bell! ;D

Indeed, outside of specific applications (various types of terminal emulators, or original equipment of historical interest) you're pretty free to use 0-31 however you like, minus the most conventional exceptions; often some in-band coding is needed, and they were originally assigned precisely this task. :)

Tim

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version