OSDev.org

Posted: **Fri Mar 22, 2024 4:51 pm**

rdos wrote:The alternatives are interpreted or JIT languages,

Rust isn't interpreted or JIT.

Posted: **Sat Mar 23, 2024 3:27 pm**

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.

Posted: **Sat Mar 23, 2024 9:52 pm**

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.

Posted: **Sat Mar 23, 2024 10:52 pm**

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.

Posted: **Mon Mar 25, 2024 1:51 am**

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.

Posted: **Mon Mar 25, 2024 10:22 am**

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.

Posted: **Tue Apr 09, 2024 2:25 pm**

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!

Posted: **Wed Apr 10, 2024 6:58 am**

eekee wrote:

Code: Select all

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: Select all

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.

Code: Select all

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.

Posted: **Fri Apr 12, 2024 4:57 am**

mikegonta wrote:Both buffers and substrings are strings, try this:

Code: Select all

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*

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.

Code: Select all

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.

OSDev.org

Intel propose simplified X86-S

Re: Intel propose simplified X86-S

Re: Intel propose simplified X86-S

Re: Intel propose simplified X86-S

Re: Intel propose simplified X86-S

Re: Intel propose simplified X86-S

Re: Intel propose simplified X86-S

Re: Intel propose simplified X86-S

Re: Intel propose simplified X86-S

Re: Intel propose simplified X86-S