| General > General Technical Chat |
| ASM programming is FASCINATING! |
| << < (10/24) > >> |
| VK3DRB:
--- Quote from: tggzzz on July 29, 2020, 07:57:48 am --- --- Quote from: VK3DRB on July 29, 2020, 01:54:01 am ---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). --- End quote --- 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. --- End quote --- 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:
--- Quote from: VK3DRB on July 29, 2020, 12:13:55 pm ---It is fun working with such fundamental microcontrollers. --- End quote --- 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!". --- Quote ---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 :-\. --- End quote --- 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:
--- Quote from: VK3DRB on July 29, 2020, 12:13:55 pm ---... 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 :-\. --- End quote --- 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... --- Quote from: peter-h on July 29, 2020, 03:14:17 pm ---- 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. --- End quote --- 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!! |
| Navigation |
| Message Index |
| Next page |
| Previous page |