Do "bits" actually mean anything with regards to a

>>3096229
ask the atari jaguar

>do the math

it was a way of marketing but not just because of it

>most modern PCs are still only 64-bit.
Even 64 bit only became important once the 32 bit address space wasn't enough to address all RAM.
Expanding the word length to 16 and 32 had similar implications. The infamous 640 KB conventional memory were a relic from the original IBM PC which used an intel 8088 which had a 8 bit external bus.

>>3096279
I thought address space and a console's bits were two different things. IIRC the NES has a 16-bit address bus because there's no way you could map all that memory to 256 bytes.

>>3096229
It's complicated.

Bits determine how big of a number the processor can work on.
Bigger numbers mean that more memory can be handled natively by the processor, bigger and smaller numbers can be used in math, and more data can be piped around in general (wider throughput on the data bus).

However, not all processes need to be 64 bit.
Like, If I have a counter that only counts to 100, then 8 bits are more than enough. On the other hand, if I'm working with coordinates in a 3d space (like polygon vertices), then I'll use a double (64 bits) because I want the extra precision. I wouldn't want the polygons to clip.

In games, having more bits also means more addressable memory. In 32 bit systems, a game can only use 4 gigabytes of RAM at once, but in 64 bit systems, 16 exabytes of RAM could be used at once.

This is also why you don't see computers racing for larger bit sizes like they once were. Adding bits results in exponential growth (16 exabytes is ridiculous). The one place I still see word sizes increasing is graphics card's memory buses, which currently go up to 256 bits. However, this is only to increase bandwidth, because 256 bits means that 4 64 bit words can be retrieved in one go.

>>3096229
The bits tell you how many lanes the processor can access memory through the cache from. So, if you had 48 bits, you could access at least 6gib of ram through the processors external bus.

>>3097627
>16 exabytes of RAM

https://www.youtube.com/watch?v=jTmXHvGZiSY

I did assembler programming professionally for about 20 years on 6502 and x86 architectures up to 2nd generation Pentiums.

>>3096229
Yeah, you could in theory make an 8-bit system that would exceed the power of an N64. You could do it with any Turing Complete processor provided enough memory and processing speed. But not easily and pretty much everything about the architecture would involve working around the limitations of being an 8-bit architecture.

You would need an elaborate paging system to access the entire program. You would be limited to working with numbers from 0 to 255 (or -128 to 127). It would be almost pointless to even include a multiplication function since 16X16 would overflow your result. Even allowing 16 bit results hardly helps the situation. Not to mention garbage precision for fractional or floating point calculations. The mathematical limitations would make any kind of 3d program stupid complicated.

The answer to all of these things is to increase the bit width. It's not just the addressing, it affects pretty much every aspect of the architecture.

>>3097279
Most architectures can address 1 magnitude above what they can process. So 8-bit processors use 16-bit addressing. 16-bit uses 32 bit addressing. Etc.

>>3096229
Genesis has 32-bit registers and 32-bit address space. If it wasn't for the 16-bit ALU it would be officially 32-bit.

>Do "bits" actually mean anything with regards to a computer's processing power?
Yes, the problem is that marketing happened to overhear the engineers using it

>>3100995
I genuinely appreciate this informative post, thanks.

>>3101061
This.

1 bit = 1 available bus for binary information
8 bit = 1 byte
16 bit = 2 bytes

So on and so forth.

File: 1457481555445.jpg (452KB, 932x820px) Image search: [Google]

452KB, 932x820px

We'll let Electronic Gaming Monthly explain.

Hope this clears things up!

>>3101117
The hell? That's a terrible article. Megabits (cartridge size) and bits (CPU register size) are two completely different things.

>>3101117
This is complete bullshit.

SNES has 24 bit address space (16MiB), Genesis has 32 bit address space (4GiB). However, the Genesis only has space in the memory map for 4MiB of ROM without bank switching, while the SNES has space for 6MiB. And with bank switching (mappers in the cart) both these limits can be exceeded.

Add in "8-bit graphics!" or "16-bit graphics" to the mix and you've got yourself a marketing nightmare.

>>3101292
>>3101117
I miss it.

It's 2016. Where's my console with 65,536 bits of processing power?

>>3102153

65,536 bit is stupid huge.
I'm not sure we even have any applications today that could even dream of using numbers that big.
I mean, I can't even post the number because it exceeds 4chans character limit, so I'll just link to it instead:

http://www.mindspring.com/~jimvb/2aa5.htm

>>3103254
With numbers that large we could finally eliminate floating point errors in Kerbal Space Program.

Bring back the bit wars!

>>3103275
you'd just shift them back a little. it's still a finite representation.
That's why it's so important that floating point algorithms are stable, and don't magnify the inherent precision errors.
Also, got any idea how much of KSPs errors is due to the resolution of the numbers? There are plenty other sources, like the temporal resolution of the computation, using unstable computations, or not even using the full available bit width

So, bit size of a processor often also means how wide (in bits) the registers (processor local storage) are.

So, a 32-bit processor probably has registers that are 4 bytes wide. A 64-bit processor has 8 bytes.

Modern processors (as in your desktop) can even operate on 128-bits at a time (16 byte registers).

So, with the correct instructions, a processor can very quickly add 3D vectors (or 4 color pixels) in a single instruction; in a smaller bit width, this operation would have to be broken up over several cycles.

>>3103297
Yeah, using bigger word sizes isn't gonna help KSP physics wise.

Infact, most errors are the result of floating point errors at high or lowspeeds or low masses.

Some examples of this are infiniglide, in which a wing going at low speeds would fly forever because the floating point errors would induce small forces on the wing, further inducing more errors and forces.

Weird orbit predictions are easy to cause by flying at a planet head on at interplanetary speeds. The engine would get a floating point error from the huge velocity and wig out.

>>3103312
The examples you mentioned would be mitigated by a bigger word size, because the threshold for floating point errors shifts

>>3103318
Still though, it only softens the problem, rather than actually optimizing the calculations responsible.

>>3103321
how would you "optimize" calculations necessarily involving the far ends of the FP range?
Also keep in mind, that doubling the FP size does not double the FP range. You're gaining orders of magnitude

>>3102153
Where are you going to find 65536 pins?

>>3104128
on the back of the CPU. That's only 256 squared. Modern CPUs already have well over 1000 pins

more bits avaliable for the processor translates to more instructions per cycle, but what you lost over time is stuff like undocumented instructions (ex. move and divide) because standardization makes things 'simpler'.

it usually cones down to what bottlenecks the speed, and visuals are all based on illusions, real life doesn't flicker in and out of existance at 60hz (quantum physics withstanding.)

tl;dr: research specs and visit /g/ sometime. just not the terribad generals.

>>3104472
>more bits avaliable for the processor translates to more instructions per cycle
how? You're not secretly talking about SIMD, which is unrelated, are you?

>but what you lost over time is stuff like undocumented instructions (ex. move and divide) because standardization makes things 'simpler'
I don't think Intel ever removed an instruction, including undocumented ones. ARM does, because they don't claim any legacy support. Don't know what WTFs others pull.

>60hz
Where does framerate come from? We're at processors

>>3104472
Non Sequitur: The Post

>>3104451
Oh, really. I never thought about it.

>>3104451
>>3105991
Still though, that's just for the RAM, not even getting into the busses you'd need for PCI ports, the northbridge, and other support hardware.

A 65536 bit processor will be quite large compared to the current sizes.

>>3108191
just make the pins smaller

Many people don't know the N64's CPU was only 64 bit due to its heritage as a processor in the MIPS 4000 series.

For practical purposes 64bitness was never really used much. There's not a whole lot of point when you are equipped with no more than 8MB of RAM.

File: 23523523.jpg (59KB, 850x476px) Image search: [Google]

59KB, 850x476px

>>3096229
Both the SNES and Genesis were 16-bits, but it was the SNES' more advanced graphic and sound chips that made all the difference (more colors, 8 PCM sound channels vs 1, higher resoultion etc.)

It's the architecture, not the bits.

>>3108364
reminder that the genesis was actually higher res most of the time.. oh forget it.

>>3108364
Funnily enough even though they ultimately are both 16 bit CPUs, the SNES one is actually a hybrid 8/16bit design and the Genesis one is a hybrid 16/32bit design.

and yes, I know you are the pro snes autismo spamming every thread

File: autismos_greatest_hits.jpg (758KB, 1153x3265px) Image search: [Google]

758KB, 1153x3265px

>>3108381
That's you! Isn't Autismo?

He was born in this thread >>3100440

He reacts violently to anyone that doesn't share his Genesis fixation and thinks there's a mysterious Nintendo boogeyman out to get him.

I've been enjoying his posts all night.

>>3103312
You'll never be able to count correctly 0.1.