Technology

59589 readers

2972 users here now

This is a most excellent place for technology news and articles.

Our Rules

Follow the lemmy.world rules.
Only tech related content.
Be excellent to each another!
Mod approved content bots can post up to 10 articles per day.
Threads asking for personal tech support may be deleted.
Politics threads may be removed.
No memes allowed as posts, OK to post as comments.
Only approved bots from the list below, to ask if your bot can be added please contact us.
Check for duplicates before posting, duplicates may be removed

Approved Bots

founded 1 year ago

MODERATORS

384

Former Intel CPU engineer details how internal x86-64 efforts were suppressed prior to AMD64's success (www.tomshardware.com)

submitted 1 month ago by Alphane_Moon@lemmy.world to c/technology@lemmy.world

73 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] Buffalox@lemmy.world 1 points 1 month ago* (last edited 1 month ago) (3 children)

Processors don’t typecast. Please stop talking.

Which is why it's such a pain, because you have to do it manually:
https://lemire.me/blog/2021/10/21/converting-binary-floating-point-numbers-to-integers/

[–] barsoap@lemm.ee 0 points 1 month ago* (last edited 1 month ago) (2 children)

I'm sorry are we somehow assuming floating-point pointers, now, of course you need to convert there. "casting" is a specific thing you do in C which may or may not involve conversion of actual data. Processors don't speak C. Processors don't have a type system.

You can use 32-bit pointers in x86_64 long mode, no issue. You don't even need to bit-fiddle: mov rax, [esi] is perfectly legal. Opcode 0x67488B06. Dereferencing rsi would be 0x488B06.

[–] Buffalox@lemmy.world 1 points 1 month ago* (last edited 1 month ago) (1 children)

I’m sorry are we somehow assuming floating-point pointers, now, of course you need to convert there.

"floating-point pointers" is not a thing:

“casting” is a specific thing you do in C

No it's not:
https://en.wikipedia.org/wiki/Type_conversion

In computer science, type conversion,[1][2] type casting,[1][3] type coercion,[3] and type juggling[4][5] are different ways of changing an expression from one data type to another.

You don't even have a clue, you are just talking trash.

In assembly you don't generally talk about pointers, but address modes. Like register, immediate or memory (indirect).

Have you ever actually been programming any serious assembly? Because you sure don't sound like it.

[–] barsoap@lemm.ee 0 points 1 month ago* (last edited 1 month ago)

Great! Now please explain how opcodes are expressions. Also, what processor instruction a cast from one pointer type to another pointer type corresponds to.

You are way out of your depth here. Have you even implemented a compiler.

EDIT:

You don’t even have a clue, you are just talking trash.

In assembly you don’t generally talk about pointers, but address modes. Like register, immediate or memory (indirect).

Have you ever actually been programming any serious assembly? Because you sure don’t sound like it.

Oh cute edit to make to make my response look bad retroactively.

But as you wanted to get pedantic: A pointer is a value which is intended to be dereferenced, that (hopefully) corresponds to a valid memory address. "address", "pointer", "reference", it's a matter of taste which one you use. It exists "in assembly" just as "an index" exists in C: Not because it's a language feature, but because it's a concept you use when writing in the language. And yes I speak pretty fluent x86, at least the non-SIMD part. Did I mention that I was there, at ground zero "why is is thing not compiling in 64 bit mode" times, fixing code?

Now, back to my question:

what processor instruction does a cast from one pointer type to another pointer type corresponds to.

Figuring out the answer to that will tell you everything you need to know about where you went wrong. Where you went from talking about actual concepts to arguing semantics.