ASM programming is FASCINATING!

[joeqsmith]

Okay, so my mind works best at the lowest possible (humanly parseable) level, with regard to machines. I find ASM particular fascinating, although I do also use bash a great deal and enjoy that, but ASM and knowing how the internal machinations of digital machines work, REALLY turns on lightbulbs in my brain.

I'm a lonnnnnnng way off knowing even 5% of what I need to know, but am gradually getting used to PIC ASM, and am now learning by messing around with an Altair 8800 simulator and loading registers by hand, and also referring to as much ASM as I can, no matter what the arch.

I've been looking here also, at 6502: http://www.obelisk.me.uk/6502/reference.html

If anyone would like to comment or advise how best to get a true, firm grasp on ASM, I'm open to suggestions.

Thanks guys and girls.

Don't.

Each instruction set is different. The hardware will be different as well.  The more of them you work with, the worse it gets.  You start making up instructions that are not there or on some other micro.  You spend hours trying to come up with better techniques, and for what?   Then you have to work on a RISC and 

We used to do everything it seems in assembler.  I had friend who worked at a fairly large company and he was in the third tier optimizing group.  The first level was the general coders.   Their stuff was clean and easy to follow and maintain.   If the code wouldn't fit, it went to the second group who would try and trim it up but keep a similar flow.  The third group would rewrite whole sections to try and get every last byte out.  The code would be nothing like the original and normally be difficult to understand.   

I don't miss those days, but when I built my little transient generator, I wire wrapped the controller using a 6801 and wrote it all in assembler.  Just for the fun of it.   That codes a mess and the whole project I would say took at least 10X longer.   

I've written a few disasseblers and debuggers for smaller micros.  I've also designed and built my own ICE.   At one point I was rolling my own CPUs.  Similar to the ucode on the 68332, create your own micro, then you can create your own uassember.   Fun, but today, there would be little point in any of it. 

[tggzzz]

The lesson on timing is, of course: if you have enough CPU power to do it, and deterministic timings, then you can hard code it; if not, then buffer it, and make sure you have enough CPU power to get through the worst-case paths to refreshing that buffer in time. 

Making sure of that is very difficult. If you measure a mean time of X, what fudge factor should you apply to get to the worst case?

As for "if you have enough cpu power", yes that is a solution. But I'm reminded that you can get a brick to fly if you apply enough power. (Or search yootoob for "flying lawnmower"!)

Indeed, modern application processors are so fast that you might not care at all, about their indeterministic execution time; an AVR or Cortex-M0 can execute one or two instructions, in the time it takes the big CPU to execute a hundred -- and those instructions are vastly more powerful, operating on more data (including SIMD extensions) in ever richer ways.  In that fraction of a microsecond, the entire computation might be complete, whereas the deterministic CPUs are just sitting down to work.

Or might not be complete.

I'm reminded of the old joke about someone entering a programming competition. The winning entry was faster, but contained errors. The losing competitor remarked that he could have made his program ten times faster if he didn't have to give the correct result.

Not to mention if multiple cores are employed (not that their outputs will be combined until much later, due to inter-CPU communication and cache coherency). 

Cache coherency is a killer, both in large systems or hard realtime systems.

The larger HPC systems appear to be settling on message passing architectures, which can avoid the problems of cache coherency.

[MK14]

Don't.

But, doing at least some assembly language. Can be fun and educational. Even a few hours at it, can be rather educational and fun. Even if that is the first and last, short assembly language program you ever end up writing.

[VK3DRB]

No one has ever written anything in assembler. But they have used an assembler and written code in assembly language. There is a big difference between an assembler and assembly language. Notepad++ now call it "Assembly" because I advised the authors several years ago they had the terminology wrong. They agreed. (Notepad++ --> Language --> A --> Assembly).

These days I write in C, but for register settings and digital I/O there is little difference between C and Assembly. I have not bothered with Assembly language for years except for some inline code occasionally. But I can see why you like Assembly language. For larger programs where there is complex program flow, C is much easier to use, read and understand.

That being said, one of the most important things in writing in assembly language (or C) is commenting. Don't comment WHAT you have done on a line-by line basis as it is pointless, but comment WHY you have done things. Use intelligent labels. Get the commenting right and use a format that ensures no ambiguity between comments or blocks of comments. Use decent good headings too. Comments will help you when you revisit the code a few years down the track. Also, it helps the "next poor bunny" that has to pick up the code. There is nothing worse than un-commented assembly code. I have seen some "professional" code written by well known companies with very amateurish commenting. Commenting in C can be reduced if intelligent identifier names and function names are used, rather than nonsensical or ambiguous names that only confuse.

[T3sl4co1l]

Making sure of that is very difficult. If you measure a mean time of X, what fudge factor should you apply to get to the worst case?

As for "if you have enough cpu power", yes that is a solution. But I'm reminded that you can get a brick to fly if you apply enough power. (Or search yootoob for "flying lawnmower"!)

Is this an argument in favor of or opposition to my post?

I like it, it's actually a really good analogy.  It highlights the same gross excess, and rational economy.

Back in the day, it took crazy defense projects (or a few very dedicated and probably wealthy amateurs) to come up with junk like that (e.g., those ill fated flying-saucer platforms).  Nowadays anyone with under a thousand bucks knocking around can slap together something like that!

In the same way, what used to require heroic assembler on one platform, with today's platforms is now trivial, even on a budget.  Don't let some imagined combination of efficiency, elegance and so on, be the barrier to "good enough"!

Doing some boring housekeeping tasks?  Don't worry about learning 8051 assembler, just slap in the AVR or STM32 you're familiar with.  Cost reduce it later when you have time -- and more importantly, budget -- to!

Using 10s technology to force 90s games to "run" on an 80s console?  Don't worry about learning VHDL for the bus interface, just use the rPi you're handy with!

Fluent in Python but the data-cranking problem would really do better on a DSP or FPGA?  Toss in the $50 SBC, who cares!

And of course not that one should take such liberty for granted: there will always be some applications where the harder solution is required, so there is value in learning lower level things (even assembly).  By all means, take the time to investigate them, as you can.

I'm reminded of the old joke about someone entering a programming competition. The winning entry was faster, but contained errors. The losing competitor remarked that he could have made his program ten times faster if he didn't have to give the correct result.

Yup.  Timing from start of instruction(s) is what I meant, of course; but knowing when they start, is another matter (or when their outputs propagate to their targets).

Cache coherency is a killer, both in large systems or hard realtime systems.

The larger HPC systems appear to be settling on message passing architectures, which can avoid the problems of cache coherency.

Reminds me of this story:
https://randomascii.wordpress.com/2018/01/07/finding-a-cpu-design-bug-in-the-xbox-360/
tl;dr they added an instruction to perform an incoherent prefetch, bypassing L2.  Turns out... just putting that instruction into memory anywhere executable at all,* introduced an extremely small probability that it would be speculatively executed, tainting coherency and setting up a crash with absolutely no warning or explanation.

*Hmm, doesn't say if it was tested quite this far.  A branch-indirect instruction could potentially be predicted to land on one, even if the target is not in any intended executable code path.  (Also assuming memory is r/w/x tagged, so that general data doesn't get spec-ex.'d; that would just about damn it to a respin, I would guess!)  Depends when and how such an instruction is decoded; maybe those are really slow on the platform, decoded late, and it's actually safe?

Tim

[KL27x]

To the OP, here's a thread that touches on many specifics of PIC ASM. Some gotcha's, some IDE tricks, some general considerations for actually writing assembly for 8 bit PIC microcontrollers. It's easy reading and might provide some insight.

https://www.eevblog.com/forum/beginners/assembly-code-help!-pic16f57/msg1857261/#msg1857261

BTW, I'm pretty sure I basically fixed the bug. But the last code change I made, like any good scientist I changed two things at once. If the guy just undoes one of those things, I bet the bug is fixed. In my defense, I had real, important work on a short timeline fall in my lap at that time. And I also completely lose interest in the final details once I know I can do it. If he had gifted me a machine, now that would have been different.

[tggzzz]

No one has ever written anything in assembler. But they have used an assembler and written code in assembly language. There is a big difference between an assembler and assembly language. Notepad++ now call it "Assembly" because I advised the authors several years ago they had the terminology wrong. They agreed. (Notepad++ --> Language --> A --> Assembly).

I'm not entirely sure what you mean, but what do you think I wrote in for my first computer? The total memory available to me in my house and at college was 128bytes.

Yes, bytes.

[tggzzz]

Don't.

But, doing at least some assembly language. Can be fun and educational. Even a few hours at it, can be rather educational and fun. Even if that is the first and last, short assembly language program you ever end up writing.

Being able to read assembly is extremely useful when doing embedded programming, and having to work out what the compiler+hardware is actually doing!

Ditto optimising the shit out of inner loops.

Ditto assuring yourself that the multicore code has the necessary memory barriers.

Plus I've used it as the basis for interview questions along the lines of "outline in pseudocode the instructions generated for a C function call".

[KL27x]

Just semantics. An assembler is analagous to a compiler. You wrote programs in assembly. The assembler turned that into machine op codes. Even if you wrote in machine code, you still didn't write in assembler/compiler.

[MK14]

Just semantics. An assembler is analagous to a compiler. You wrote programs in assembly. The assembler turned that into machine op codes. Even if you wrote in machine code, you still didn't write in assembler/compiler.

As well as calling it, "I just wrote an assembly program", people also in practice seem to say "I wrote it in assembler".

But people never seem to say "I wrote it in compiler".

Similarly, paper, when printed, is then called a newspaper.
But you might say to someone, (when you want the newspaper) "please hand me the paper", or "Please go and fetch the paper".

[westfw]

Quote

getting used to PIC ASM, and am now learning by messing around with an Altair 8800 simulator ... I've been looking here also, at 6502

I would strongly suggest investing time in a modern processor, rather than all those historical beasts.MIPS (ie PIC32), ARM, or RISC-V...
(the problem is, you won't find nearly as much tutorial material on how to program them in assembly language.)

[tggzzz]

Making sure of that is very difficult. If you measure a mean time of X, what fudge factor should you apply to get to the worst case?

As for "if you have enough cpu power", yes that is a solution. But I'm reminded that you can get a brick to fly if you apply enough power. (Or search yootoob for "flying lawnmower"!)

Is this an argument in favor of or opposition to my post?

Yes

I like it, it's actually a really good analogy.  It highlights the same gross excess, and rational economy.

Back in the day, it took crazy defense projects (or a few very dedicated and probably wealthy amateurs) to come up with junk like that (e.g., those ill fated flying-saucer platforms).  Nowadays anyone with under a thousand bucks knocking around can slap together something like that!

In the same way, what used to require heroic assembler on one platform, with today's platforms is now trivial, even on a budget.  Don't let some imagined combination of efficiency, elegance and so on, be the barrier to "good enough"!

Doing some boring housekeeping tasks?  Don't worry about learning 8051 assembler, just slap in the AVR or STM32 you're familiar with.  Cost reduce it later when you have time -- and more importantly, budget -- to!

Using 10s technology to force 90s games to "run" on an 80s console?  Don't worry about learning VHDL for the bus interface, just use the rPi you're handy with!

Fluent in Python but the data-cranking problem would really do better on a DSP or FPGA?  Toss in the $50 SBC, who cares!

And of course not that one should take such liberty for granted: there will always be some applications where the harder solution is required, so there is value in learning lower level things (even assembly).  By all means, take the time to investigate them, as you can.

No argument there, but what underutilisation fudge factor should you employ to guarantee to meet timing constraints.

My professional experience includes both hard realtime embedded systems (where "deadline" was the right term), and soft realtime systems where the mean latency was important. The former is "challenging" if you have caches around - it is best to disable them.

I'm reminded of the old joke about someone entering a programming competition. The winning entry was faster, but contained errors. The losing competitor remarked that he could have made his program ten times faster if he didn't have to give the correct result.

Yup.  Timing from start of instruction(s) is what I meant, of course; but knowing when they start, is another matter (or when their outputs propagate to their targets).

Cache coherency is a killer, both in large systems or hard realtime systems.

The larger HPC systems appear to be settling on message passing architectures, which can avoid the problems of cache coherency.

Reminds me of this story:
https://randomascii.wordpress.com/2018/01/07/finding-a-cpu-design-bug-in-the-xbox-360/
tl;dr they added an instruction to perform an incoherent prefetch, bypassing L2.  Turns out... just putting that instruction into memory anywhere executable at all,* introduced an extremely small probability that it would be speculatively executed, tainting coherency and setting up a crash with absolutely no warning or explanation.

*Hmm, doesn't say if it was tested quite this far.  A branch-indirect instruction could potentially be predicted to land on one, even if the target is not in any intended executable code path.  (Also assuming memory is r/w/x tagged, so that general data doesn't get spec-ex.'d; that would just about damn it to a respin, I would guess!)  Depends when and how such an instruction is decoded; maybe those are really slow on the platform, decoded late, and it's actually safe?

I haven't heard that story, but it doesn't surprise me. I've deliberately avoided looking at the data sheet and errata for modern x86 processors. As Tony Hoare put it in his Turing award lecture, "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. It demands the same skill, devotion, insight, and even inspiration as the discovery of the simple physical laws which underlie the complex phenomena of nature."

Having said that, the xCORE processor I used had zero errata and the processor's hardware-software co-design made it a delight to use. Programming it was fun, not a battle.

[KL27x]

people also in practice seem to say "I wrote it in assembler".

Yeah, and it doesn't bother me, at all. People also "compile" their assembly into a hex.

edit: I have yet to hear anyone recompile their assembler. That might bug me.

[MK14]

people also in practice seem to say "I wrote it in assembler".

Yeah, and it doesn't bother me, at all. People also "compile" their assembly into a hex.

Which they then upload  download into the cpu.

[Psi]

Yep, ASM is definitely fascinating. 
I wouldn't want to write a massive windows app in it, but it definitely gives you a good appreciation for how things work behind the scenes.

I took a class in computer architecture and then advanced computer architecture at uni in my computing degree,  it was very worthwhile.
Then after that degree i got another one in electronics with emphasis on mcu programming. hehe

[Ian.M]

To the OP, here's a thread that touches on many specifics of PIC ASM. Some gotcha's, some IDE tricks, some general considerations for actually writing assembly for 8 bit PIC microcontrollers. It's easy reading and might provide some insight.

https://www.eevblog.com/forum/beginners/assembly-code-help!-pic16f57/msg1857261/#msg1857261

BTW, I'm pretty sure I basically fixed the bug. But the last code change I made, like any good scientist I changed two things at once. If the guy just undoes one of those things, I bet the bug is fixed. In my defense, I had real, important work on a short timeline fall in my lap at that time. And I also completely lose interest in the final details once I know I can do it. If he had gifted me a machine, now that would have been different.

@KT27x: Fixed the link for you.

@all,
I was an interested bystander and limited participant in that thread.  IIRC It was an exercise in patching the worst spaghetti code that has been seen here in many years on a deeply unfavourable architecture.

IMHO Assembly language programming of complex projects on the baseline (12 bit) PIC core risks brain damage to all participating sapient lifeforms vulnerable to impact trauma, and not capable of directed autistic savant hyperfocus.  For your own safety, please use adequate PPE (e.g. boxing helmet and thick padding on desk and cubicle walls  ), and have your significant other on standby with a tranquilliser, straitjacket and your preferred choice of sedatives.    If you engage in rubber duck debugging, you will find that the ducks are a consumable resource! 

The classic and extended midrange (14 bit) PIC cores are much less trauma inducing, and can actually be satisfying to code for (in a hair-shirt ascetic sort of way).

TLDR: If the second group of numbers in a PIC12 or PIC16 part number begins with a '5', run screaming for the hills!

[ebastler]

I have yet to hear anyone recompile their assembler. That might bug me.

Yep, me too.

On a loosely related note: Is there a commonly accepted term for the process of translating VHDL or Verilog into an FPGA configuration binary? "I synthesized, mapped, placed & routed it" is a bit long. 

[Ian.M]

"I built the binary from the ....." or is that over-simplistic?

[mfro]

I have yet to hear anyone recompile their assembler. That might bug me.

Yep, me too.

On a loosely related note: Is there a commonly accepted term for the process of translating VHDL or Verilog into an FPGA configuration binary? "I synthesized, mapped, placed & routed it" is a bit long. 

Recompiling my assembler regularly - with every binutils upgrade.

[joeqsmith]

I took a class where we used an old computer using machine code.  You found yourself memorizing the hex codes for the instructions.  There was no debugger so you would enter your code and just see if it worked.   There was no way to store your program and you had to key it in everytime you worked on it.   The first time I used an assember was after taking that class.     I'm not sure if the punch cards were any better....   

[VK3DRB]

No one has ever written anything in assembler. But they have used an assembler and written code in assembly language. There is a big difference between an assembler and assembly language. Notepad++ now call it "Assembly" because I advised the authors several years ago they had the terminology wrong. They agreed. (Notepad++ --> Language --> A --> Assembly).

I'm not entirely sure what you mean, but what do you think I wrote in for my first computer? The total memory available to me in my house and at college was 128bytes.

Yes, bytes.

You wrote it in Assembly language. An Assembler is a type of compiler which produces object code from source code. It is a tool, not a language. It is a common mistake that people call Assembly language Assembler.

128 bytes is pretty small. Some really brilliant coders were Dan and Kathe Spracklen who write Sargon for the TRS-80. They did a brilliant job with the graphical Chess game for which I was never able to beat the machine after level 4 of 8 levels. So little memory they had to deal with - 4kB (that's 4096 BYTES) if I recall. They deserved a Nobel Prize for what they achieved  .

The lowest level I got was writing in hexadecimal machine code for a 6502 in an Apple II clone to make a Morse Code trainer. It worked a treat. There was no way its BASIC interpreter could generate deterministic dits, dahs and pauses at different speeds. Assembly would have worked, but I did not have an assembler handy. Much more recently about 10 years ago I developed an interractive Morse Code beacon - written entirely in C on an ATmega128 (with some audio phonemes and phrases added by a radio announcer into a speech recording chip), which has been transmitting FM on 145.650MHz for the past 10 year continuously across the city of Melbourne. Accurate timings for the Morse up to ridiculously high speeds, but I limited it from 2WPM to 30WPM (because the spare RAM would run out because it stores the previous few minutes of Morse Code in bit patterns for subsequent reading back in speech).

It is fun working with such fundamental microcontrollers. I am working with some Linux developers on an ARM7 based MCU. They cannot do a lot of things that are done easily with low level MCUs. They need to find a driver that someone has written. This causes a major headache because it has limited the peripheral choices I have had to design into a PCB. Now they say they cannot even guarantee a 32.768kHz clock output frequency to within 500ppm to drive a WiFi/BT module's sleep mode, so I had to use a hardware oscillator to do it  .

[tggzzz]

It is fun working with such fundamental microcontrollers.

Then you wonder how to implement a mid-level processor such as a PDP11. You notice all the rx<-rx+1 and pc<-pc-123 and rx<-[ry]+[rz++] type operations, and think "hmm, each of those looks like several steps in a programming language".

And at that stage you have triumphantly re-invented microprogramming. Then you notice the AMD2900 family, and go "ah ha!".

I am working with some Linux developers on an ARM7 based MCU. They cannot do a lot of things that are done easily with low level MCUs. They need to find a driver that someone has written. This causes a major headache because it has limited the peripheral choices I have had to design into a PCB. Now they say they cannot even guarantee a 32.768kHz clock output frequency to within 500ppm to drive a WiFi/BT module's sleep mode, so I had to use a hardware oscillator to do it  .

Yes indeed, the trick is to find the right boundaries between hardware and various levels of software.

The nice thing about 486 MSDOS computers was that once MSDOS had loaded your program (and no others), you could completely ignore it.

[mfro]

... I am working with some Linux developers on an ARM7 based MCU. They cannot do a lot of things that are done easily with low level MCUs. They need to find a driver that someone has written. This causes a major headache because it has limited the peripheral choices I have had to design into a PCB. Now they say they cannot even guarantee a 32.768kHz clock output frequency to within 500ppm to drive a WiFi/BT module's sleep mode, so I had to use a hardware oscillator to do it  .

Did you ever think you might be talking to the wrong people?
It appears to me as if what you are really searching for is Linux drivers developers.
These are the guys that are talking to the hardware directly and probably can provide you with the features you are expecting.

[peter-h]

Today, the main use of asm programming is

- CPU and peripheral register initialisation which needs to be exactly right and often needs to be loaded in a particular order e.g. some registers are not accessible until after another has been suitably configured. Most people do this in C too, but they would be mostly stuck if they could not copy startup code ripped off from the dev kit source examples

- Squeezing last drop of speed in some tight algorithm. However, to really make this shine you need to take a rather lateral look at the job and make use of side effects. For example most (all?) C compilers will implement a 16 bit integer x10 multiply with, ahem, a 16x16=32 multiply routine, or by calling a MULT instruction if there is one (not on a Z80, but a Z180 has one), but a shift left, save, shift left twice more, add, gives you x10 and is probably the fastest of all unless the CPU has a barrel shifter which you may get on a $8 ARM with 10M transistors, but not on a $1 chip... I have seen C compilers which try to identify these special cases but they can't do them all; say x9? Or x11? And most C compilers are truly horrible with floats; e.g. one IAR Z80 one implemented a sscanf() with a float mult for each digit converted (taking tens of milliseconds!!!!!) but not only is this garbage but if e.g. you know the multiplier is just an 8 bit value you can shortcut it by a hack on the mantissa and an increment on the exponent, which can be 1000x faster... etc. On the $8 ARM 32F I would probably not bother but it all depends on how far you are pushing it in your project. And somebody will point out that the above x10 can be done in C also, with shifts etc.

- Self modifying code. This is pretty dirty but a great technique for some very fast stuff. Normally one doesn't modify opcodes but modifies the data fields in an instruction. It can speed up code several times.

- Timing loops. There are cases where you need a precise delay, and you can afford to disable interrupts. A C compiler can do that too, but its next upgrade might optimise that loop out, and it will happen 5 years after the original programmer has left...

- A simple development environment. I have a few Atmel 90S1200 (obsolete now) products going and the whole devt environment is a DOS directory with the assembler, the source file, and a batch file for running the assembler Modern graphical devt environments are massive things, with big learning curves, and it will take you days to get back into it after a few years. Or it may not even run if the machine got upgraded from winXP to win10, etc. So futureproofing gets hard. But the old asm kit runs under a winXP VM for ever. Actually you get the same issues with FPGAs which is why I dumped any involvement in them many years ago (Xilinx); the tools and the learning curves, and copy protection, just got more and more horrible.

- An easy learning curve. It is really easy to get into asm programming. And really easy to pick up a project after 10 years to do a small mod to it (use Notepad).

[Brumby]

If you are into swinging on monkey bars with 11KV 3 phase on adjacent rungs, then you'll enjoy this...

- Self modifying code. This is pretty dirty but a great technique for some very fast stuff. Normally one doesn't modify opcodes but modifies the data fields in an instruction. It can speed up code several times.

Doing this requires great care.  If you have any conceivable element of luck in your approach or risk assessment - don't.  It WILL blow up on you.

My advice is - DO NOT do this.  Look for a more conventional approach - BUT if you absolutely have to resort to something like this - DOCUMENT THE HELL OUT OF IT!!