Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail From: mitchalsup@aol.com (MitchAlsup1) Newsgroups: comp.arch Subject: Re: Segments Date: Mon, 6 Jan 2025 23:41:41 +0000 Organization: Rocksolid Light Message-ID: <8ea06df32cff07e30dd477b425dbdd0a@www.novabbs.org> References: <2024Oct4.193007@mips.complang.tuwien.ac.at> <2024Oct6.150415@mips.complang.tuwien.ac.at> <2025Jan3.093849@mips.complang.tuwien.ac.at> <2025Jan5.121028@mips.complang.tuwien.ac.at> <2025Jan6.092443@mips.complang.tuwien.ac.at> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: i2pn2.org; logging-data="2365095"; mail-complaints-to="usenet@i2pn2.org"; posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU"; User-Agent: Rocksolid Light X-Rslight-Site: $2y$10$C/5uDIfgqmHRjePiRTpCsuaaU4m/7sdhww.apv.cmsa4.o7vwvexi X-Spam-Checker-Version: SpamAssassin 4.0.0 X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71 Bytes: 2922 Lines: 41 On Mon, 6 Jan 2025 22:02:30 +0000, Thomas Koenig wrote: > Hmm... a beginning of an idea (for which I am ready to be shot > down, this is comp.arch :-) > > This would work best for languages which explicitly pass > array bounds or sizes (like Fortran's assumed size arrays, > or, if I read this correctly, Rust's slices). > > Assume a class of load and store instructions containing > > - One source or destination register > - One base register > - One index register > - One ubound register > > Memory access is to base + index, with one additional point: > If index > ubound, then the instruction raises an exception. Now, you are only checking the ubound and not the lbound; so, you only stumble over ½ the bound errors. Where you should START is with a data structure that defines the memory region:: First Byte accessible Possibly lbound Last Byte accessible Possibly ubound other stuff as needed Then figure out how to efficiently perform the checks in ISA of choice (or add to ISA). > This works less well with C's pointers, for which you would have > to pass some sort of fat pointer. Compilers would have to make > sure that the address of the base object is passed. I blame the programmers for not using FAT pointers (and then teaching the compilers how to get rid of most of the checks.) Nothing is preventing C programmers from using FAT pointers, and thereby avoid all those buffer overruns. > Comments?