“What the Hardware Does” Is Not What Your Program Does: Uninitialized Memory

Re:“What the Hardware Does” Is Not What Your Program Does: U... by scoutt on Monday July 15, 2019 @04:08AM (#20438953)

I appreciate the attempt to explain low-level stuff, but I think this is a high-level language programmer trying to understand herself/himself an issue without a clear idea of what he/she is talking about

>> The answer is that every byte in memory cannot just have a value in 0..256,

0..256?? Is this still 8-bits bytes??

>> it can also be “uninitialized”. Memory remembers if you initialized it.

This is plainly wrong.

>> So, one time we “look” at x it can be at least 150, and then when we look at it again it is less than 120, even though x did not change. x was just uninitialized all the time.

You might be dealing with a bug on a non-volatile variable. It has nothing to do with allocated but uninitialized memory.

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by noobermin on Monday July 15, 2019 @04:40AM (#20439073)

The problem here (and I caught it too and sort of recoiled at it) was they were using their logic and worse language/word choice regarding the "abstract machine" being the actual thing we should think about when reasoning about a programming language before they actually went out and were explicit that's what they were doing. They saved the explicit thesis until the end of the piece. They should have traded the writer's desire to be witty and hide the lede and just lead with it upfront.

Of course you're right in part that their idea of "memory" is an abstraction, but it isn't too wrong. A "variable" in C or any compiled language on a modern machine is an abstraction that could refer to a register one moment, be a place in the cache in another, be a place in memory in the next, and be on a swapfile after. The "variables" are abstractions which lie in "memory" which is another abstraction because it need not be in one place.

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by ralfjung on Monday July 15, 2019 @07:48AM (#20439901)

Good point, I should have at least mentioned that there is an "abstract machine" when I introduce this strange kind of memory. Thanks for the feedback!

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by littlestymaar on Monday July 15, 2019 @12:03PM (#20442073)

> I think this is a high-level language programmer trying to understand herself/himself an issue without a clear idea of what he/she is talking about

FYI The author is a PhD student working on optimizing compiler.

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by dancek on Monday July 15, 2019 @04:28AM (#20439030)

> 0..256?? Is this still 8-bits bytes??

In Rust a..b means the range a <= x < b, so yes, that is an 8-bit byte.

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by scoutt on Monday July 15, 2019 @04:47AM (#20439093)

An 8-bit byte can hold 256 values, from 0 to 255, and cannot hold a value = 256, whatever the philosophy is.

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by ChrisSD on Monday July 15, 2019 @05:21AM (#20439211)

Read what dancek said again. In Rust `a..b` means

    a <= x < b

So 0..256 is

    0 <= x < 256

That is "less than" 256. There's no equals (that would be `0..=256` in Rust).

[ Parent | on HN ]

Re:“What the Hardware Does” Is Not What Your Program Does: U... by scoutt on Monday July 15, 2019 @05:49AM (#20439312)

Oh my....

Well, I guess the author realized about the confusion in every other non-Rust programmer it generates (https://git.ralfj.de/web.git/commitdiff/13622f8642fc071bedf3...).

[ Parent | on HN ]