Deutsch   English   Français   Italiano  
<vlk88j$2d9j6$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Thomas Koenig <tkoenig@netcologne.de>
Newsgroups: comp.arch
Subject: Re: Segments
Date: Tue, 7 Jan 2025 22:01:55 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 56
Message-ID: <vlk88j$2d9j6$1@dont-email.me>
References: <vdlgl9$3kq50$2@dont-email.me>
 <2024Oct6.150415@mips.complang.tuwien.ac.at>
 <vl7m2b$6iat$1@paganini.bofh.team>
 <2025Jan3.093849@mips.complang.tuwien.ac.at>
 <vlcddh$j2gr$1@paganini.bofh.team>
 <2025Jan5.121028@mips.complang.tuwien.ac.at>
 <vleuou$rv85$1@paganini.bofh.team>
 <ndamnjpnt8pkllatkdgq9qn2turaao1f0a@4ax.com>
 <2025Jan6.092443@mips.complang.tuwien.ac.at> <vlgreu$1lsr9$1@dont-email.me>
 <vlhjtm$1qrs5$1@dont-email.me> <bdZeP.23664$Hfb1.16566@fx46.iad>
 <vlj1pg$25p0e$1@dont-email.me> <W3bfP.515961$DYF8.447613@fx14.iad>
 <20250107170429.00003de2@yahoo.com>
 <18cc69cf39bb7b0df7fc8733f9ccaab6@www.novabbs.org>
Injection-Date: Tue, 07 Jan 2025 23:01:56 +0100 (CET)
Injection-Info: dont-email.me; posting-host="b4538e50db6eae8949cc6a23d1a47c8e";
	logging-data="2532966"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+nHRQWSYYNrtv/HNhPsWQ5cI3MNR4sE2I="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:pZx8l8+qGIpKCXb3fblCzfaNz2g=
Bytes: 3501

MitchAlsup1 <mitchalsup@aol.com> schrieb:
> On Tue, 7 Jan 2025 15:04:29 +0000, Michael S wrote:
>
>> On Tue, 07 Jan 2025 14:43:02 GMT
>> scott@slp53.sl.home (Scott Lurndal) wrote:
>>
>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>>Scott Lurndal <scott@slp53.sl.home> schrieb:
>>>>
>>>>>>Assume a class of load and store instructions containing
>>>>>>
>>>>>>- One source or destination register
>>>>>>- One base register
>>>>>>- One index register
>>>>>>- One ubound register
>>>>>
>>>>> See aforementioned CHERI.
>>>>
>>>>CHERY targets C, which on the one hand, I understand (there's a
>>>>ton of C code out there), but trying to retrofit a safe memory
>>>>model onto C seems a bit awkward - it might have been better to
>>>>target a language which has arrays in the first place, unlike C.
>>>>
>>>>The floating point size is weird (and also does not catch all
>>>>errors, such as writing one element past a huge array).
>>>>
>>>>I haven't seen any consideration of how CHERI would integrate
>>>>with languages which have multidimensional arrays.  How would
>>>>
>>>>  do j=1,10
>>>>    do i=1,11
>>>>      a(i,j) = 42.
>>>>    end do
>>>>  end do
>>>>
>>>>interact with Cheri if a was a 10*10 array ?  Would it be
>>>>necessary to create a capability for a(:,j)?
>>>
>>> A multidimensional array is a single contiguous
>>> blob of memory, the capability would encompass the
>>> entire region of memory containing the array.
>>
>> Then out of bound access like a(9,11) would not be caught.
>> I don't know if it has to be caught by Fortran rules. It is certainly
>> caught both in Matlab and in Octave. And Matlab has Fortran roots.
>
> WATFIV would catch a(9,11)

Every Fortran compiler I know has a bounds checking, but it is
optional for all of them. People still leave it off for production
code because it is too slow.

It would really be great if the performance degradation was
small enough so people would simply leave on the checks
for production code.  (Side question: What does CHERI
do with SIMD-vectorized code?)