General > General Technical Chat
ASM programming is FASCINATING!
<< < (4/24) > >>
tggzzz:

--- Quote from: Kleinstein on July 28, 2020, 12:09:40 pm ---ASM programming is still sometimes done with µCs. I does offer the advantage of a well defined run time. So those old days style waiting loops get accurate.

--- End quote ---

Only in very simple processors that don't have any cache, don't have interrupts, and are strictly in-order.

Even then it is difficult to guarantee timing in all but the simplest systems or  the most lightly loaded systems. If you doubt that, specify which scheduling algorithm you are using, and find a way toconvince other people that your implementation meets the requirements. That is surprisingly difficult.

There is, as MK14 notes, one modern alternative that guarantees hard realtime performance by design: the xCORE processors running xC. They use parallism to avoid the need for interrupts, use hyperthreading techniques to avoid the need for cache, have FPGA-like i/o structures, and the IDE inspects the (optimised) code to determine the exact timing between here and there. No other processor comes close.
SiliconWizard:

--- Quote from: tggzzz on July 28, 2020, 02:53:52 pm ---
--- Quote from: Kleinstein on July 28, 2020, 12:09:40 pm ---ASM programming is still sometimes done with µCs. I does offer the advantage of a well defined run time. So those old days style waiting loops get accurate.

--- End quote ---

Only in very simple processors that don't have any cache, don't have interrupts, and are strictly in-order.

Even then it is difficult to guarantee timing in all but the simplest systems or  the most lightly loaded systems. If you doubt that, specify which scheduling algorithm you are using, and find a way toconvince other people that your implementation meets the requirements. That is surprisingly difficult.

--- End quote ---

Yep.
The "last" processors I did that on - already over 15 years ago now - were PIC16F/18F CPUs. Cycles per instruction were fully documented and fixed for all instructions, and you could indeed predict execution time with 1 cycle accuracy. If you needed *short* and accurate delays, like just a few cycles, that was pretty much the only way.
I did that with even older processors, such as the Z80 - with interrupts disabled.


--- Quote from: tggzzz on July 28, 2020, 02:53:52 pm ---There is, as MK14 notes, one modern alternative that guarantees hard realtime performance by design: the xCORE processors running xC. They use parallism to avoid the need for interrupts, use hyperthreading techniques to avoid the need for cache, have FPGA-like i/o structures, and the IDE inspects the (optimised) code to determine the exact timing between here and there. No other processor comes close.

--- End quote ---

Yeah. Definitely a completely different architecture.

Getting back to the topic, programming in assembly these days on modern processors can be certainly fun and somewhat fascinating, you can indeed get more performance this way - if you're very good, otherwise most compilers will beat you to it - but don't expect to be able to accurately predict execution time. Or stick to the very simple processors. As I mentioned, that's something you can still do with PIC16F/18F MCUs for instance, which are still available.

As to getting a "good grasp" on ASM? I would probably start as we used to back in the days - first study the architecture of common (and simple) processors, get to know everything they are able to execute (arithmetic ops, logic ops, branches, memory move, etc.) and then learn the corresponding assembly. At this point, it'll be easier to understand what every assembly intruction does and WHY it has been implemented. Then of course, look at a lot of code examples, and write your own. If you're interested in the 6502, I think you'll find thousands of resources for that.
NivagSwerdna:
Of course there is also the joy of reverse engineering using Ida Pro or Ghidra or the like.

If you are interested in computer security etc... then Buffer Overflow attacks are fun and there are plenty of tutorials out there..

e.g.

If that's your thing then Linux, gcc and gdb are your friends.

Have fun!


MK14:

--- Quote from: MK14 on July 28, 2020, 12:32:28 pm ---
--- Quote from: Kleinstein on July 28, 2020, 12:09:40 pm ---I does offer the advantage of a well defined run time. So those old days style waiting loops get accurate.

--- End quote ---

With the rather old processors/architectures, your are right. The odd modern one, here and there can be an exception as well (e.g. XCore).

Disclaimer: The above paragraphs were written quickly and may have small (or bigger) technical inaccuracies. If you are really interested in this stuff, there is some good/interesting stuff (books and good internet stuff) out there.

--- End quote ---

No one else seems to have so far, so I will 'attack' my own post.

Actually, no, even the old processors, were not necessarily, cycle by cycle accurate.

Examples:
WAIT state lines (might be called something else, depends on cpu, e.g. ready), which inserts wait states, to help with slower memory, I/O and sometimes other things. Some schemes are somewhat non-deterministic (e.g. a video card, which may or may not, be accessing the video memory, at the same instant in time).

If the looping software is waiting for a bit or value, in an internal or external peripheral, to occur or change, the timing can be asynchronous and/or random. Because (e.g. the A to D converter), the precise timing may depend on how long the analogue and/or digital circuitry, takes (potentially asynchronous to the master cpu clock).

Some instructions, have a variable number of cycles, depending on the exact values, and don't seem to bother to define what they are. E.g. Some integer divide instructions. Might say, takes from 2 to 15 cycles, depending on values involved. It could be deterministic, if you researched how the cycle count varies, but most people probably won't do that. There could be documentation somewhere that defines it (e.g. each 1 in specified register, adds a cycle to the time plus a minimum of 2 cycles plus address mode penalty cycle count).

Not an exhaustive list. Also not the best of examples, because they are sort of deterministic, it is just the exact times in practice will vary, depending on somewhat defined things (such as A to D response time variation) etc.
chris_leyson:
I think the most fun I've ever had writing assembler was for Motorola DSP chips. You always had to keep an eye on how your data was moving, which busses or registers were free to move the data and then sometimes tweak the order of operations so as not to get an arithmetic, transfer or status stall whereupon the assembler would add a NOP instruction. I was good fun interleaving mathematical operations and data moves in order to keep the ALU as busy as possible. NXP still do the 56k family.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod