OSDev.org

The Place to Start for Operating System Developers
It is currently Wed May 29, 2024 2:46 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 54 posts ]  Go to page Previous  1, 2, 3, 4
Author Message
 Post subject: Re: Intel propose simplified X86-S
PostPosted: Fri Mar 22, 2024 4:51 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5182
rdos wrote:
The alternatives are interpreted or JIT languages,

Rust isn't interpreted or JIT.


Top
 Profile  
 
 Post subject: Re: Intel propose simplified X86-S
PostPosted: Sat Mar 23, 2024 3:27 pm 
Offline
Member
Member
User avatar

Joined: Mon May 22, 2017 5:56 am
Posts: 826
Location: Hyperspace
Octocontrabass wrote:
runtime bounds checks

These were traditionally considered to be slow. Has that changed, or are we just putting up with the performance loss? I never thought it was a big loss, and I guess I'm not alone as there have always been languages with runtime bounds checks.

I guess functional programming allows much bounds checking to be eliminated as an iterator cannot exceed the range of its input data, though I'm not so sure about output.

_________________
Kaph — a modular OS intended to be easy and fun to administer and code for.
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie


Top
 Profile  
 
 Post subject: Re: Intel propose simplified X86-S
PostPosted: Sat Mar 23, 2024 9:52 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5182
I don't know if software bounds checking was especially slow in the first place, but it's gotten faster as compilers have gotten better.


Top
 Profile  
 
 Post subject: Re: Intel propose simplified X86-S
PostPosted: Sat Mar 23, 2024 10:52 pm 
Offline
Member
Member

Joined: Wed Aug 30, 2017 8:24 am
Posts: 1619
eekee wrote:
These were traditionally considered to be slow.
"Slow" is relative. But yes, this idea that it is slow is why in C++ std::vector doesn't do bounds checking in operator[], and why the recalcitrant old farts in the standards committee nixed bounds checking from Microsoft's std::span proposal, so that the standard version again doesn't have it.

In reality, a bounds check is going to be at most a subtract, compare, and conditional branch. That is slower than branchless code, but faster than, say, a cache miss. And way faster than a system call. I can see applications where it matters, but for the vast majority of them it doesn't.

_________________
Carpe diem!


Top
 Profile  
 
 Post subject: Re: Intel propose simplified X86-S
PostPosted: Mon Mar 25, 2024 1:51 am 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 3196
Octocontrabass wrote:
I don't know if software bounds checking was especially slow in the first place, but it's gotten faster as compilers have gotten better.


Bounds checking is not enough to ensure memory is not overwritten. The most common problems causing this is pointers that are misused (casted to an incorrect type), pointers that are freed but still used, and using completely incorrect pointers loaded from memory trash. Paging is only moderately efficient at solving the last case. Segmentation is moderately efficient at solving the first case, and very efficient for the other two. It also solves bounds checking without any additional requirements.


Top
 Profile  
 
 Post subject: Re: Intel propose simplified X86-S
PostPosted: Mon Mar 25, 2024 10:22 am 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5182
rdos wrote:
The most common problems causing this is pointers that are misused (casted to an incorrect type),

Pointer casts are bypassing the language's type checking, they're always going to be dangerous no matter which language you're using. Even C has pointer type checks! The solution is to make pointer casts unnecessary by designing better APIs.

rdos wrote:
pointers that are freed but still used,

Rust prevents this.

rdos wrote:
and using completely incorrect pointers loaded from memory trash.

Any language that forces memory initialization before use prevents this.

rdos wrote:
Segmentation [...] solves bounds checking without any additional requirements.

It requires you to fit all your bounds-checked pointers into your GDT and/or LDT.


Top
 Profile  
 
 Post subject: Re: Intel propose simplified X86-S
PostPosted: Tue Apr 09, 2024 2:25 pm 
Offline
Member
Member
User avatar

Joined: Mon May 22, 2017 5:56 am
Posts: 826
Location: Hyperspace
nullplan wrote:
eekee wrote:
These were traditionally considered to be slow.
"Slow" is relative. But yes, this idea that it is slow is why in C++ std::vector doesn't do bounds checking in operator[], and why the recalcitrant old farts in the standards committee nixed bounds checking from Microsoft's std::span proposal, so that the standard version again doesn't have it.

In reality, a bounds check is going to be at most a subtract, compare, and conditional branch. That is slower than branchless code, but faster than, say, a cache miss. And way faster than a system call. I can see applications where it matters, but for the vast majority of them it doesn't.

Thanks for the reminder; that isn't much overhead at all. Still, I can see a reason for not doing it in a tight loop on a big array. `foreach itm in items` seems like a good construct for that case, but there are some things which are easier to code with an indexed loop. Oh, I suppose this is what those `map` and `zip` functions were for in that Lisp tutorial I took years ago. Map applied a function to each element of a list. Zip applied a function to elements from multiple lists. (I might have got the names wrong.)


Octocontrabass wrote:
rdos wrote:
The most common problems causing this is pointers that are misused (casted to an incorrect type),

Pointer casts are bypassing the language's type checking, they're always going to be dangerous no matter which language you're using. Even C has pointer type checks! The solution is to make pointer casts unnecessary by designing better APIs.

I thought for a while that CAL-4700 (to give the specific version of the plain English compiler I'm using and its language) was quite type safe, but there was a time I had to code a cast from buffer to string type. The types are the same; "a buffer is a string" is right there in the code, but the compiler refuses to pass buffers to string routines. I had to code up a cast myself, which on the one hand worries me more than using a built-in cast, but on the other hand isn't something I'm going to do lightly. Here's the code, and yes I know it's bad to use a literal non-ASCII character like that; I was going to change it after I sorted the other issues. Comments are italicized. "A string" is actually 2 pointers; the string is stored elsewhere in malloc'd memory.

To decide if a buffer is png-format:
\If the buffer starts with "‰PNG", say yes. \ compiler doesn't know a buffer is a string, even though it's been told.
\Slap a substring on the buffer. If the substring starts with "‰PNG", say yes. \ compiler doesn't know a *substring* is a string, even though it's been told.

Put the buffer's first into a string's first.
Put the buffer's length into the string's last.
If the string starts with "‰PNG", say yes.
Say no.

I should email the author and see what they say, but I keep thinking I'll do it when I'm feeling less confused. It'll never happen until I have some RL support, I think. I've been thinking, the last time I coded something I'm proud of, I had help with life stuff. As a result of that help, I was healthier.

Octocontrabass wrote:
rdos wrote:
pointers that are freed but still used,

Rust prevents this.

rdos wrote:
and using completely incorrect pointers loaded from memory trash.

Any language that forces memory initialization before use prevents this.

Good practice using CAL-4700 prevents these, but if I have to break good practice as in the code I pasted... :| I worry!

_________________
Kaph — a modular OS intended to be easy and fun to administer and code for.
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie


Top
 Profile  
 
 Post subject: Re: Intel propose simplified X86-S
PostPosted: Wed Apr 10, 2024 6:58 am 
Offline
Member
Member

Joined: Thu May 19, 2011 5:13 am
Posts: 229
eekee wrote:
Code:
To decide if a buffer is png-format:
[i]\If the buffer starts with "‰PNG", say yes. \ compiler doesn't know a buffer is a string, even though it's been told.
\Slap a substring on the buffer. If the substring starts with "‰PNG", say yes. \ compiler doesn't know a *substring* is a string, even though it's been told.[/i]
Put the buffer's first into a string's first.
Put the buffer's length into the string's last.
If the string starts with "‰PNG", say yes.
Say no.
Both buffers and substrings are strings, try this:
Code:
To run:
  Start up.
  Append "‰PNG" to a buffer.
  If the buffer is png-format, debug "a buffer is a string".
  Shut down.

To decide if a buffer is png-format:
  If the buffer starts with "‰PNG", say yes.
\  Slap a substring on the buffer.
\  If the substring starts with "‰PNG", say yes.
  Say no.
Quote:
Code:
Put the buffer's first into a string's first.
Put the buffer's length into the string's last.
This won't work.
The string's last needs to be the buffer's last or the string's first plus the buffer's length minus 1.

_________________
Mike Gonta
look and see - many look but few see

https://mikegonta.com


Top
 Profile  
 
 Post subject: Re: Intel propose simplified X86-S
PostPosted: Fri Apr 12, 2024 4:57 am 
Offline
Member
Member
User avatar

Joined: Mon May 22, 2017 5:56 am
Posts: 826
Location: Hyperspace
mikegonta wrote:
Both buffers and substrings are strings, try this:
Code:
To run:
  Start up.
  Append "‰PNG" to a buffer.
  If the buffer is png-format, debug "a buffer is a string".
  Shut down.

To decide if a buffer is png-format:
  If the buffer starts with "‰PNG", say yes.
\  Slap a substring on the buffer.
\  If the substring starts with "‰PNG", say yes.
  Say no.

*tries it* :shock: How does that work? lol! I was sure I tried a string operation on a buffer just as the manual describes and it didn't work. I must have misunderstood something at the time of that test. But I'm sure I tried the exact decider you wrote (without the comments) and it didn't work. Today, in your test case, it works. Probing... It does work in the real code. Well, that's humbling. I thought I had tried it. I must have misread an error message.

Quote:
Code:
Put the buffer's first into a string's first.
Put the buffer's length into the string's last.
This won't work.
The string's last needs to be the buffer's last or the string's first plus the buffer's length minus 1.[/quote]
Oops! "Length" there was basically a typo, it should have been "last". I'm glad you noticed, it could perhaps have had nasty effects in some circumstances. This is a reason not to code casts by hand.

Both of these things had the same cause. Processing input is the hardest thing for my brain, so it skips stuff and fills in the gaps with things it thinks it knows. Everyone's brain does this, but it's much worse in my brain than most. Autism.

EDIT: I've just rediscovered that the compiler makes very poor error messages if you accidentally use "the" insead of "a" in a routine header. It "imagines" faults in subsequent lines. For instance, I was working on "To open a node given a buffer (file as png-picture);" but accidentally typed it as, "To open a node given the buffer (file as png-picture)". (Emphasis added.) The first line of the routine was an if-condition, and teh compiler reported "Error: I need a decider"... for a condition which I had copy/pasted from a working line. Such a bad error message is very likely the source of my misunderstanding. But even if it gets fixed, I still need to find a strategy to catch my typos. Not that anyone can ever code entirely without typos, and no compiler can catch them all. :)

_________________
Kaph — a modular OS intended to be easy and fun to administer and code for.
"May wisdom, fun, and the greater good shine forth in all your work." — Leo Brodie


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 54 posts ]  Go to page Previous  1, 2, 3, 4

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 10 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group