Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: [OT] SPARC (was Re: The integral type 'byte')
Date: Fri, 28 Mar 2025 10:26:06 -0700
Organization: A noiseless patient Spider
Lines: 92
Message-ID: <vs6m3f$35a2q$4@dont-email.me>
References: <vrd77d$3nvtf$2@dont-email.me> <86r02roqdq.fsf@linuxsc.com>
 <vrh1br$35029$2@dont-email.me> <LRUCP.2$541.0@fx47.iad>
 <vrh71t$3be42$1@dont-email.me> <vrh9vh$3ev9o$1@dont-email.me>
 <vrhct4$3frk8$2@dont-email.me> <20250320204642.0000423a@yahoo.com>
 <vrhphb$3s62l$1@dont-email.me> <87iko3s3h2.fsf@nosuchdomain.example.com>
 <vrrvgp$1828d$1@dont-email.me> <874izi82a4.fsf@nosuchdomain.example.com>
 <vrttin$321rm$1@dont-email.me> <vrus18$3srn9$1@dont-email.me>
 <vruttb$3tpl0$1@dont-email.me> <vrv15d$1gs4$1@dont-email.me>
 <vs0kv7$1hb4h$2@dont-email.me> <vs11oi$1tp3r$1@dont-email.me>
 <vs1b8b$24nub$5@dont-email.me> <vs1ftc$2a7cq$1@dont-email.me>
 <vs225e$2pgqi$1@dont-email.me> <vs2ctp$34jvu$1@dont-email.me>
 <vs3lu9$di1m$1@dont-email.me> <vs4vqf$1jono$1@dont-email.me>
 <vs502d$1jq5h$1@dont-email.me> <vs51ck$1l7fv$1@dont-email.me>
 <20250328132623.000031de@yahoo.com> <vs63fe$2m8r2$2@dont-email.me>
 <20250328152036.00005bf3@yahoo.com> <vs6c0n$2tqti$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 28 Mar 2025 18:26:08 +0100 (CET)
Injection-Info: dont-email.me; posting-host="7ce1f9b3539f865da57caab62bfa1cad";
	logging-data="3319898"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18rcy1oUzqPmuI0MgYijbwSdb+/DFWJiFc="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:u8xC9kmMcsMDzuGaGnIdI3Phfys=
Content-Language: en-US
In-Reply-To: <vs6c0n$2tqti$1@dont-email.me>
Bytes: 6024

On 3/28/2025 7:33 AM, David Brown wrote:
> On 28/03/2025 13:20, Michael S wrote:
>> On Fri, 28 Mar 2025 13:08:14 +0100
>> David Brown <david.brown@hesbynett.no> wrote:
>>
>>> On 28/03/2025 11:26, Michael S wrote:
>>>> On Fri, 28 Mar 2025 03:26:26 +0100
>>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>>>> On 28.03.2025 03:03, Chris M. Thomasson wrote:
>>>>>> On 3/27/2025 6:59 PM, Janis Papanagnou wrote:
>>>>>>>
>>>>>>> But there were ideas! But not only the interesting ideas (like
>>>>>>> the frame shift on the stack [SPARC]; one detail I memorized)
>>>>>>
>>>>>> It's been a while since I coded up raw SPARC ASM. Remember that
>>>>>> branch delay slot? Ever use it with a MEMBAR instruction? Shit
>>>>>> would hit the fan.
>>>>>
>>>>> As mentioned somewhere upthread I haven't ever programmed a SPARC
>>>>> on assembler level, just studied some documents. I'm not even sure
>>>>> the term "frame shift on the stack" that I used is accurate or
>>>>> correct; it's just an informal description of a technical detail
>>>>> that I had considered to be interesting. (Instead of copying
>>>>> parameters/results with function calls between callers and callee
>>>>> you could just shift a "stack window" by adjusting a register (or
>>>>> so).
>>>>>
>>>>> So, no, I cannot remember a "branch delay slot". - Sorry. - Want to
>>>>> elaborate on the story?
>>>>>
>>>>> Janis
>>>>
>>>> You didn't ever programmed in SPARC asm. Your reading of SPARC
>>>> documents was so shallow that you didn't pay attention to highly
>>>> visible distinguishing feature as branch delay slot.
>>>
>>> I have not programmed SPARC either, but I would not consider branch
>>> delay slots to be a distinguishing feature - delay slots were a
>>> common feature in many (but not all) RISC architectures - most
>>> notably, IMHO, MIPS.
>>>
>>> The register window concept, however, was a lot less common (though
>>> not unique to the SPARC), and much more relevant to the way you work
>>> with the processor.
>>>
>>
>> Register Window is a major part of Berkeley tradition. The processor
>> with Register Window that was sold and highest quantities is probably
>> not SPARC, but Intel i960. Another examples are AMD 29K and Intel
>> Itanium.
> 
> I did not know that the Itanium had a register window - I did know about 
> the AMD 29K.  It surprises me to hear that the i960 was sold in higher 
> quantities than the SPARC, but since I have no real idea of the sales 
> figures of either, I will take your word for it.
> 
>>
>> As to importance for asm coder, branch delay slot is more important
>> (i.e. more annoying) than register window, simply because in typical
>> program one has more branches than function calls.
> 
> I would disagree.  Neither feature is particularly relevant if you are 
> doing user-level programming in a high-level language.  In assembly, you 
> have no choice but to understand and use the register window feature - 
> it's a major part of coding.  The branch delay slot, on the other hand, 
> can be ignored by simply using a NOP, for a slight efficiency cost.  

I also remember reading in some SPARC manual about using NOP's in branch 
delay slots. Programming the SPARC was really "fun" when it was in RMO 
mode... :^)


> I 
> vaguely recall the MIPS assembler handling delay slots somewhat 
> automatically, but my experience using that was /very/ brief.  Make the 
> most of the delay slot for optimal efficiency would, I expect, be 
> annoying - but so is a lot of assembly coding for RISC devices!
> 
> 
>> At system programming level register window can be more important, in a
>> bad way.
>> At the level of programming in C, esp. for application programs, both
>> register windows and branch delay slots are transparent.
>>
> 
> Yes.
> 
> Any classification of "distinguishing features" or "important features" 
> is going to be quite subjective - it depends which other cpus you are 
> comparing to.
>