Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Don Y <blockedofcourse@foo.invalid>
Newsgroups: sci.electronics.design
Subject: Re: Why Bloat Is Still Software's Biggest Vulnerability
Date: Tue, 12 Mar 2024 11:39:19 -0700
Organization: A noiseless patient Spider
Lines: 55
Message-ID: <usq7gr$ee8q$1@dont-email.me>
References: <uq9qak$1l12i$1@solani.org> <980294@dontemail.com>
 <uqbbhm$148o2$1@dont-email.me>
 <a41e1c56-b3e9-4f60-832e-1bbd5aa2a1b5n@googlegroups.com>
 <uspk8m$91ne$4@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 12 Mar 2024 18:39:24 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="cd61f5e18330181594e65cc325aef3d5";
	logging-data="473370"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19jnQp7RL+x7yxwBVN5qVpr"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:pcEFnKXZ3VcCrFGSq5tMpOWfK8M=
In-Reply-To: <uspk8m$91ne$4@dont-email.me>
Content-Language: en-US
Bytes: 3061

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)
>    );
> }
>