Path: ...!eternal-september.org!feeder3.eternal-september.org!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Why VAX Was the Ultimate CISC and Not RISC
Date: Fri, 7 Mar 2025 22:51:13 +0000
Organization: Rocksolid Light
Message-ID: <dd54322f623ee8b0bfde844042747071@www.novabbs.org>
References: <vpufbv$4qc5$1@dont-email.me> <2025Mar1.125817@mips.complang.tuwien.ac.at> <vpvrn5$2hq0$1@gal.iecc.com> <2025Mar1.232526@mips.complang.tuwien.ac.at> <vq2dfr$2skk$1@gal.iecc.com> <2025Mar2.234011@mips.complang.tuwien.ac.at> <5pkg9l-kipt.ln1@msc27.me.uk> <2025Mar3.174417@mips.complang.tuwien.ac.at> <vq4qav$1dksd$1@dont-email.me> <vq5dm2$1h3mg$5@dont-email.me> <2025Mar4.110420@mips.complang.tuwien.ac.at> <vq829a$232tl$6@dont-email.me> <2025Mar5.083636@mips.complang.tuwien.ac.at> <vqdljd$29f8f$2@paganini.bofh.team> <vqdrh9$3cdrc$1@dont-email.me> <vqek6h$3fro6$1@dont-email.me> <fe70b48cd6fef0aaf89278163d8b6322@www.novabbs.org> <vqfmr4$3npgk$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="3348575"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
X-Rslight-Site: $2y$10$uopjhOhLV8ax9SiPV.xv/uwX63ZW/XDmqOLSw/DIhbsQmomKed0YG
Bytes: 3151
Lines: 48

On Fri, 7 Mar 2025 21:00:09 +0000, BGB wrote:

> On 3/7/2025 11:34 AM, MitchAlsup1 wrote:
>> On Fri, 7 Mar 2025 11:08:56 +0000, BGB wrote:
>>
>>> On 3/6/2025 10:09 PM, Lawrence D'Oliveiro wrote:
>> ----------------
>>>
>>> So, writing things like:
>>>    y[55:48]=x[19:12];
>>
>> 2 instructions in My 66000. One extract, one insert.
>>
>
> 1 instruction in this case...
>
> The 3 sub-fields being, 36, 48, and 56.
>
> The way I defined things does mean adding 1 to the high bit in the
> encoding, so 63:56 would be expressed as 64:56, which nominally uses 1
> more bit of range. Though, if expressed in 6 bits, the behavior I had
> defined it as, effectively causes it to be modulo.

My 66000 uses the same trick, allowing both 64 and 0 to indicate
64-bits.

>> ----------------------
>>>
>>> For a simple test:
>>>    lj[ 7: 0]=li[31:24];
>>>    lj[15: 8]=li[23:16];
>>>    lj[23:16]=li[15: 8];
>>>    lj[31:24]=li[ 7: 0];
>>> Does seem to compile down to 4 instructions.
>>
>> 1 innstruction:: BITR rd,rs1,<8>
>>
>
> In this particular case, there is also a SWAP.L instruction, but I was
> ignoring it for sake of this example, and my compiler isn't that clever.
------------
>
> Unlike Verilog, in C mode it will currently require single-bit fetch to
> use a notation like x[17:17], but this is more because a person is much
> more likely to type "x[17]" by accident (such as by using the wrong
> variable, a missing '*', or ...).

I use <1,16> where the first is the length of the field, and the second
is the offset from bit<0>.