No that would be silly since updating drivers doesn’t change the hardware the game is running on. So not sure how this example is relevant to porting.
AMD RDNA5 Architecture Speculation
- Thread starter Frenetic Pony
- Start date
No that would be silly since updating drivers doesn’t change the hardware the game is running on. So not sure how this example is relevant to porting.
If it didn't, why would a recompilation be necessary?
/s
I know there are no clear lines but as long as you don't have to manually change anything I don't consider it porting.
Do you consider Java a portable language?
Exactly. People consider Java to be portable even though from their perspective there’s no manual work required. I’m not sure what it is you’re disagreeing with to be honest. This is pretty standard terminology now.
Also somewhat depends on your perspective of the code that's being changed.
My single line program:
... has to go through a compiler before my target device can execute it. The compiler takes the "high level" code (yes, even C is high level in this example) and compiles it to a target architecture. The end result is, if I compile my program for ARM, or X86/32, or Motorola PPC, the generated assembly code from the compiler absolutely changes as the compiler target does. This is ultimately how Java is a "portable" language -- it's not about the high level, human readable code, it's about just-in-time compiled assembly instructions specifically fitted to the runtime architecture. Java is porting code in real time, versus a static compiler which would port the human-generated code at the time of a static compile.
(Re-)compiling can absolutely fit the definition of code being ported.
My single line program:
Code:
Printf "Hello World";(Re-)compiling can absolutely fit the definition of code being ported.