Path: ...!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: Wed, 13 Mar 2024 16:47:10 -0700
Organization: A noiseless patient Spider
Lines: 50
Message-ID: <ustdu4$176f7$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>
 <ussk9p$v99p$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 13 Mar 2024 23:47:17 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="11f1a6c097d5e8318048522ef22246c2";
	logging-data="1284583"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18eNR/odr//egc4/lJHxhFz"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:bsGSFdkhQOso60g51C90Ntseptk=
Content-Language: en-US
In-Reply-To: <ussk9p$v99p$2@dont-email.me>
Bytes: 3256

On 3/13/2024 9:29 AM, Peter wrote:
> 
>   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.

For *new* hardware, yes.  But, still present in older designs
(that likely need to be maintained)

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

There are lots of ways to make money.  The joy of engineering is
that you can have *fun* -- and learn stuff -- while doing so!
(imagine being an *accountant*, lawyer, doctor, etc. -- fields where
"new knowledge" drips out at a trickle...)