[x64] Cures startup in front of PureBasicStart

Share your advanced PureBasic knowledge/code with the community.
Ramihyn_
Enthusiast
Enthusiast
Posts: 314
Joined: Fri Feb 24, 2006 9:40 am

Re: [x64] Cures startup in front of PureBasicStart

Post by Ramihyn_ »

sys64802 wrote:I don't even want to go near the "image is quality up" claim which is just coming from a different universe.
True, i totally ignored that part too :)
Thorium
Addict
Addict
Posts: 1271
Joined: Sat Aug 15, 2009 6:59 pm

Re: [x64] Cures startup in front of PureBasicStart

Post by Thorium »

Ramihyn_ wrote:I wasn't talking about instruction interference, but interference by emitted electromagnetic waves. Its certainly an esoteric topic, but it does exist and has uses even nowadays. This is not the place to talk about it, but its not just a wacko idea. If you seriously want to dig into this, you needed laboratory equipment 20 years ago already, not sure if that's still "enough" nowadays due to the frequencies.
True, what i mean is that there is no unpredicted interaction between instructions and or memory access which will alter program execution in any way. Which is what oryaaaaa is talking about, as i understood him.
Chip designers actualy put a lot of work into preventing that.
Ramihyn_ wrote: About undocumented opcodes, feel free to read up here http://www.rcollins.org/secrets/

Obviously the undocumented "features" nowadays can be obstructed and hidden better. Historically they where basically side effects of discreet logic circuits nobody documented. Nothing to do with intentionally hiding anything.
There might be features that are intentionaly hidden. However thats not what "undocumented opcodes" typicly are. In the old days undocumented opcodes was been instructions that wasnt been intended by the chip designer. They existed because of the way the instruction decoders was been made. A not used (not designed) opcode could trigger gates that actualy would do something usefull in a way the chip designer didnt thought about. Thats why they wasnt been documented, because the chip designer them self didnt knew about them. Today the instruction decoder will throw a "invalid instruction" exception if you try to run a instruction with a uninteded opcode. Thats to ensure secure execution of the code, so couldnt use a uninteded way to get ring0 for example.
Post Reply