General > General Technical Chat

ASM programming is FASCINATING!

<< < (22/24) > >>

westfw:

--- Quote ---In many cases we were achieving the same thing
--- End quote ---
I've been somewhat amused that ARM CM0 doesn't have the "shifted constant" version of MOV, but that you can load a small constant and then do a shift, in the same amount of space.  (you don't get the other weird modes of MOV constant, but ... they are less common.)

VK3DRB:

--- Quote from: MK14 on August 01, 2020, 04:44:33 pm ---Yes, assembler, can be a rather hard and daunting subject, to master....

--- End quote ---

Rubbish. Assembler is easy. Just read the manual that came with the assembler or macro assembler. These compilers are not hard to master.

Assembly on the other hand can be a little hard and daunting for newcomers. A good place to start is read the datasheets and the programming literature for a particular microcontroller. Use an emulator or ICE or other debug tool. For Microchip, the PICkits are a good tool to step through your code to know what is going on. A "hello world" can be as simple as configuring a UART and echoing a character back; or just flashing an LED; or even just loading a register and reading it back.

Berni:

--- Quote from: VK3DRB on August 02, 2020, 05:59:03 am ---
--- Quote from: MK14 on August 01, 2020, 04:44:33 pm ---Yes, assembler, can be a rather hard and daunting subject, to master....

--- End quote ---

Rubbish. Assembler is easy. Just read the manual that came with the assembler or macro assembler. These compilers are not hard to master.

Assembly on the other hand can be a little hard and daunting for newcomers. A good place to start is read the datasheets and the programming literature for a particular microcontroller. Use an emulator or ICE or other debug tool. For Microchip, the PICkits are a good tool to step through your code to know what is going on. A "hello world" can be as simple as configuring a UART and echoing a character back; or just flashing an LED; or even just loading a register and reading it back.

--- End quote ---

Its one thing figuring out the tiny instruction set of a PIC16F where you have something like 35 opcodes in total. In fact its so simple that a single Wikipedia page covers all the information needed to write assembly for all the PIC families from PIC12 to PIC24: https://en.wikipedia.org/wiki/PIC_instruction_listings

The modern x86 instruction set has >1000 instructions. There is a mountain of internal registers, lots of them sticking around for legacy reasons. In terms of execution time the instructions can have complex dependencies due to how the pipeline works. For example you get instructions like PMOVZXBW with a huge long opcode of "66 0F 38 30 [r]" that just simply does "Zero extend 8 packed 8-bit integers to 8 packed 16-bit integers". Sure you don't need to know all of it and can get by with the basic move, math and conditionals but you will have a hard time beating C when it comes to writing a reasonably complicated algorithm. You need to know a LOT to be able to write assembler that is more optimized than what C spits out. While writing the C code does that is a lot easier and requires less knowledge (And can be applied to other architectures too).

Still this is no reason to never touch assembler. Knowing the basics of how assembler works on your particular architecture can really help you understand what C has to do in order to make things happen. This makes it easier to understand the occasional oddities in C and help you write faster C code. If nothing else you can look at the disassembly and check any critical tight loops for any potential improvements. But writing whole apps in assembler doesn't make sense these days. The actual app tends to get complex enough already, so you don't want to make it even harder by having all the code look like endless unreadable towers of instructions with no format while having think about how to do something rather than just writing it out as a single line of code. You can still stick some inline assembler in a C function to hand optimize a fast loop if needed, but leave the mountain of other non critical stuff to C.

Ian.M:

--- Quote from: KL27x on August 02, 2020, 03:33:47 am ---You don't do retlw lookup tables because it's the only way to do it. You do it where it's convenient. We still use them in 14 bit PIC, because they're still convenient.

In my own code, 90% of my "returns" could be "retlw [arbitrary value]." And I still use retlw data tables. When deciding what to cram into the 12 bit core, they left out the one of two instructions that was less valuable with the easier work around. "Return" is more expendable. The only place where it's not expendable is return from an interrupt. And here, you have retfie, only. You don't have retfielw (which here would be almost useless).

--- End quote ---
Actually the baseline core doesn't even have RETFIE, because it doesn't have *any* interrupts!   

The interrupt capable enhanced baseline core (which very few PICs use, IIRC only PIC16F527, PIC16F570 & PIC16HV540) shoehorns an extra three instructions into the 12 bit core instruction decoder, including both RETFIE to support interrupts and RETURN, and also, to make it semi-usable, increases the stack to four levels.


--- Quote from: VK3DRB on August 02, 2020, 05:59:03 am ---Assembly on the other hand can be a little hard and daunting for newcomers. A good place to start is read the datasheets and the programming literature for a particular microcontroller. Use an emulator or ICE or other debug tool. For Microchip, the PICkits are a good tool to step through your code to know what is going on. A "hello world" can be as simple as configuring a UART and echoing a character back; or just flashing an LED; or even just loading a register and reading it back.

--- End quote ---
On learning PIC assembly language by doing: 

A PICkit (2 to 4) is a great debugging aid *IF* your target supports debugging.  To do so, the PIC must have hardware debug support built into its silicon*. Baseline PICs, many midrange PICs and some enhanced midrange PICs don't.   Choose a debug capable PIC and enjoy learning by stepping through your code instruction by instruction, watching the actual effect of pins changing in your target circuit.

OTOH The MPLAB IDE simulator is cycle accurate for the core.  Its also reasonably good for supported peripherals, but a lot of the more interesting peripherals are either only partially supported or aren't supported at all.   However, you can simulate anywhere, without having to be tethered to that big mess of wires and chips on your bench!

* For some non-debug-capable PICs you can buy an expensive and fragile 'debug header', which includes a  special debug capable version of the target, with additional pins bonded out to support the ICD interface on a footprint converter board. They are a PITA to work with on anything other than DIP footprint target boards.  Unless you are backed into a corner avoid Microchip 'debug headers' as choosing a debug capable PIC in the first place with enough pins to reserve the three ICSP/ICD ones for programming and debugging is almost always a better option.   You may say "but cheeseparing management demands I save $0.02 on the BOM" and forces you to choose a non-debug-capable PIC , but nowadays there's almost certainly an even cheaper debug capable enhanced midrange device that can do the job.

KL27x:

--- Quote ---Actually the baseline core doesn't even have RETFIE, because it doesn't have *any* interrupts! 
--- End quote ---

Oh, yeah. I keep forgetting that. Westf has pointed that out to me before a couple of times. I'm glad he refrained and allowed you, this time. I kinda moved on from baseline before even turning my attention to interrupts, and I somehow got the idea that they must have them, too. (The only reason I said that the 12F54/7 "fruit machine" code didn't have an ISR was that literally there was no interrupt code in the program. It didn't occur to me that it wasn't even possible, at the time I said it.)


--- Quote ---The interrupt capable enhanced baseline core (which very few PICs use, IIRC only PIC16F527, PIC16F570 & PIC16HV540) shoehorns an extra three instructions into the 12 bit core instruction decoder, including both RETFIE to support interrupts and RETURN, and also, to make it semi-usable, increases the stack to four levels.

--- End quote ---

Cool, yeah. It makes much more sense this way. That return and retfie are introduced together. Because at the core, I can't really imagine why retfie and return would need to occupy separate chunks of the core, at all. I wonder if they are really only distinguished by the IDE for error handling and semantics? I suppose once an interrupt handler is added, retlw is the more dispensable one of the two.

edit: oh. Well, that only holds up until you add automatic context-saving. So you still need some etra core space to distinguish between return and retfie at that stage, but maybe not completely redundant. But without automatic context-saving (which many older PICs don't have) it seems like retfie and return should be interchangeable other than your IDE or assembler wouldn't allow it.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod