Path: ...!feeds.phibee-telecom.net!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Peter <occassionally-confused@nospam.co.uk>
Newsgroups: sci.electronics.design
Subject: Re: Why Bloat Is Still Software's Biggest Vulnerability
Date: Wed, 13 Mar 2024 16:29:47 +0000
Organization: A noiseless patient Spider
Lines: 40
Message-ID: <ussk9p$v99p$2@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> <usq7gr$ee8q$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 13 Mar 2024 16:29:45 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="54c69d9a693696d2f2b2203254acd0cd";
	logging-data="1025337"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+tFCdM2nyPnrwWyCF73Vej"
Cancel-Lock: sha1:81F3tQ6B51eDUxGfBFqKOGgM7ZA=
X-Newsreader: Forte Agent 3.3/32.846
X-No-Archive: yes
Bytes: 2719


 Don Y <blockedofcourse@foo.invalid> wrote:

>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)?

I think I/O is rare; it tends to be memory mapped.

>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.

I'll leave that to the next generation. I want to make a bit of money
now :)