Re: Why Bloat Is Still Software's Biggest Vulnerability

On 3/12/2024 6:10 AM, Peter wrote:

   RichD <r_delaney2001@yahoo.com> wrote:
 

Given these considerations, does anybody write assembly code for
modern RISC processors?

 Yes; some stuff cannot be done in C. Start with loading SP. No way in
C!

Doing anything that isn't memory-mapped; how would you generate "I/O"
instructions (for processors with I/O spaces)?
Using any part of the instruction set that isn't directly mapped
to native C constructs (how would you access support for BCD
data types?  special commands to control interrupts?  opcodes to
control atomic operations/synchronization?)

Some code in an RTOS is not possible in C. Look at the FreeRTOS
sourcecode. There are bits of asm in there.
 Also asm has great uses for protecting from optimisation (which can
change silently by upgrading the compiler!). Asm never gets modified;
essential when talking to devices needing specific minimum /CS timing
etc.

This is changing.  Lots of ongoing work in optimizing and
super-optimizing assembly language code.  Even arguments
being made that compilers should NOT be generating (final)
ASM, from HLL sources cuz it forces them to know too
much about the underlying hardware... things that a
(truly) "optimizing assembler" is better suited to knowing.
[E.g., how bondout options can change the costs of different
opcodes from one processor in a "family" to another]

Another example, for accurate delays (ST32F417, 168MHz)
 // Hang around for delay in microseconds
 __attribute__((noinline))
void hang_around_us(uint32_t delay)
{
   delay *= (SystemCoreClock/4100000L);
    asm volatile (
     "1: subs %[delay], %[delay], #1 \n"
     "   nop \n"
     "   bne 1b \n"
     : [delay] "+l"(delay)
   );
}