I can assume that because I wrote this code and I know the implications it bears. For example: jnz is a short jump, what 2 GBs are you talking about? 127 bytes max. Brainless patching can lead you anywhere.

OMG the 8086 only has single byte signed conditional jumps. We will never be able to program anything in the 8086.

Hehe, there is always a way around things. Don't complain, be pragmatic, and don't waste your time worrying about something that will never happen in your programming career. Who can write even 2MB+ of assembled code? 1000 times bigger, 2GB+ ... forget about it, there would be so many bugs that it wouldn't run well anyway.

Okay a quick computation:

• 2GB of assembled code (minimum size to trigger a problem with a long jump)
• Leads to probably around 20GB of source code
• Assuming you can type perfect code without bugs and without need to edit and whatnot, let's say about 5 characters per second
• There are ~31557600 seconds in a year
• 20GB/5cps/31557600 = ~136 years just to type the source code
• And that is without any form of debugging or even toilet/food/sleep breaks (408 years with 8 hours per day of constant typing)
• Can you honestly say you can produce 2GB+ of assembled code (not data) and need to jump huge distances and have it all run satisfactorily without too many bugs?
• And what app needs such a huge code base anyway?

sometimes, problems are created to be just problems.

maybe a recursive virtual code or a set of useless macros can create a 2GB executable.

for example:



then, convert every instructions by a macro.



making that for all instructions, and then, code with these macros.
i presume executable will be very big.

i have a better idea.
create hardware that will probe your mind and translate yout thoughts into program.
your idea -> machine representation.

and now using this neural link create complicated simulation of something, for example some biological process on subatomic scale.

And here we are. code is 2GB+, and we cant conditional jump or even return to highle nested loops.


Now intel/amd must do something about this, they add 8 byte jumps to the list, dumping all existing PCs in the world.

If this neural interface would do HLL code, problem is partial, because on unsupported machines you can use cmov'c (with penalty of bigger code).

Sounds scary. Translating my thoughts into machine code? Yikes, some of the things I think would be best to never be translated into code!

When your idea comes true, CPU will probably already have FPGA-like features that will work more efficiently. GPUs (which today are already capable of more than just graphics, see CUDA for instance), will be enormously parallel (they already are, but will much more, again, probably with some FPGA-like structure if not already). In any case, looks that the idea needs to be data driven much more that code driven.

The penalty BTW, it is not so clear, having a ten bytes instruction for conditional jumps seriously consumes decoding bandwidth, so unless you add separate opcodes for those not-needed-in-our-lifetime Jcc rel64 but instead promote Jcc rel32 to rel64 then thanks but I prefer the CPU just as it is now.

if it is for a neural network, you can use 16 bit structures and values, then, work on them with 32 bits code, and then, you will have all the needed features to do a neural network.

let imagine a neron like a structure.

value is a 16bits value
vptr, k, p, i and d will be pointers, not values.
then, if it is 16bits pointers, it will be easy to fit in a cyclic address space.
k = cooeficient for the PID
p = product of value and [vptr]
i = integral of value
d = differential of value


create 65536 neurons like this.
use a pointer to point to a vlaue of a neuron

and maybe it will do something interresting. i don't know, but i imagine it can be interesting.

with 32 bits, you will need a lot of memory just to contain the 4G neurons.

but all in all, a conditional jump don't have to jump so far, because it is in a local algorythm, it is named functions.

we create functions to simplify the code, and avoid bugs.

fpga?
wtf i though it was my idea