Path: ...!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Split instruction and immediate stream
Date: Sun, 23 Mar 2025 16:51:40 +0000
Organization: Rocksolid Light
Message-ID: <2a3083d504c018964d09cf5014a42dc8@www.novabbs.org>
References: <vqhjpv$65am$1@dont-email.me> <vqiikd$c35o$1@dont-email.me> <fmnzP.432863$2zn8.70525@fx15.iad> <16462d5aa26345e4e015f240b30bba02@www.novabbs.org> <vrm4vt$3o4ta$1@dont-email.me> <vrmjhv$5hkp$1@dont-email.me> <vrntrs$1ab2q$1@dont-email.me> <vrotr9$2atc0$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="1436890"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$1vavUpgMc9segFG3isytoup6O.MilOs/zalC2sAhqjfNgN6MyTZCu
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
Bytes: 3912
Lines: 58

On Sun, 23 Mar 2025 12:12:25 +0000, Marcus wrote:

> Den 2025-03-23 kl. 04:06, skrev Robert Finch:
>> On 2025-03-22 11:04 a.m., Thomas Koenig wrote:
>>> Marcus <m.delete@this.bitsnbites.eu> schrieb:
>>>
>>>> Then we have the page-crossing issue. Is it better to force the
>>>> compiler/assembler to align such instructions so that they never cross
>>>> page boundaries?
>>>
>>> Power 10 chose to do so; actually, larger instructions cannot
>>> cross a (likely) Cache line size there.  According to the Power
>>> ISA Version 3.1, section 1.6:
>>>
>>> "Prefixed instructions do not cross 64-byte instruction address
>>> boundaries. When a prefixed instruction crosses a 64-byte boundary,
>>> the system alignment error handler is invoked."
>>
>> In the latest test project, the LB650 similar to a PowerPC, large
>> constants are encoded at the end of the cache line. So, there is a
>> similar issue of code running into the constant area.
>>
>> I have the assembler moving the code that overlaps to the next cache
>> line.
>>
>> It is confusing to look at listing files, as there are constants output
>> inline with the code. Makes it look like the code should not work. How
>> does it know where to go for the next instruction? Is the question that
>> comes to mind.
>>
>> For now, the hardware decoder takes the cheezy approach of marking
>> instructions fetched in the constant area as invalid. The constant area
>> gets fetched and loaded into the pipeline, but as NOPs.
>>
>> It is quite a trick getting the assembler to place constants at the end
>> of the cache line and generate references to the constants. It is
>> interesting because I have *constants* being relocated by the assembler
>> / linker. Normally there would not be a relocation associated with a
>> constant. A relocation reference to the constant is spit out by the
>> assembler, and the linker updates the index to the constant in the code.
>>
>> It does not quite work yet. Constants are placed and code is moved, but
>> the linked program does not have the correct references yet.
>>
>> Experimental, but looking like things will work.
>>
>
> Although I have not tried any of these techniques, here are my thoughts.
>
> Why not always place the constant next to (right after) the instruction
> that references it, instead of at an offset within the cache line?
>
> The effect should be very similar, but now you have a simpler offset
> (it's always zero) and you eliminate the problem with having to keep
> track of where the constants are in order to prevent the PC/IP from
> running into the constant area.

You also don't need to worry about cache line (i.e., artificial)
boundaries.