4 ms·

You could continue this argument out to 128 or 256 bits. Where it starts to fall down is when you map the size of those address spaces back to the data types pe

by mschaef 10y ago

You could continue this argument out to 128 or 256 bits. Where it starts to fall down is when you map the size of those address spaces back to the data types people work with. In a 16-bit address space (64K), you hit the 16-bit limit _all the time_. Even a moderately sized text document will be bigger than 64K... and that's before considering images, videos, large data sets, etc. 32-bit takes you out to 4GB, which is much more likely to hold a typical working set, so the argument to go to 64-bit is much less pressing. "why not stick with 8 bit?" This conversation is about the size of the address space, not the machine word size. To my knowledge, there were no serious machines of any sort that were limited to an 8-bit address space. (Maybe something homebrew or embedded.) The closest I can think of is the 6502's preference for putting values in the zero page (which was 256 bytes).

wolfgke 10y ago
> In a 16-bit address space (64K), you hit the 16-bit limit _all the time_. Depends on the way 16 bit is implemented. For example x86-16 uses segmented memory - enabling adressing of a little bit more (including High Memory Area) than 1 MiB of memory. The Z180 uses as far as I know a MMU (but not completely sure). Another approach that is/was in common use is to use bank switching. Depending on the kind of algorithm that you use this can make the coding much more complicated or can also be no problem, because the scheme that is used to address more memory than 2^16 bytes fits the algorithm quite natural. One interesting hack for example when coding in real mode (x86-16) that I read about is rather to use some clever sharing of bits between the segment register value and segment index: - One scheme is to consider the value of the used segment register as a pointer to a 16 byte block of memory and use the segment index to adress the specific byte in this block (with an option to increase the index "a little bit" if you want to go further) - Another scheme is to (mostly) use only the 4 highest bits of the segment register (and zero all the other ones).
- mschaef 10y ago
  "One scheme is to consider the value of the used segment register as a pointer to a 16 byte block of memory and use the segment index to adress the specific byte in this block (with an option to increase the index "a little bit" if you want to go further)" This only works in real mode, where the segment is shifted and directly added to the offset. In protected mode, it goes through a selector table. This can be made to work too, but it requires tiled allocations of segments with known delta between each segment. This is what __ahincr was about, if you remember it from the Win16 days.
  - wolfgke 10y ago
    > This only works in real mode, where the segment is shifted and directly added to the offset. In protected mode, it goes through a selector table. Of course this is true. You wrote further above: > In a 16-bit address space (64K), you hit the 16-bit limit _all the time_. I wanted to outline that whether this is a problem or not depends a lot on the concrete 16 bit architecture.
    - mschaef 10y ago
      Are you thinking of a specific concrete 16-bit architecture where it's easy to access data objects larger than 64K? I'd be interested to hears... I really can't. Probably the most capable architecture I'm familiar with that has a native 16-bit pointer type is the 80286, which provides 24-bit physical addressing, virtualizatoin, protections, etc. Even then, at least on Windows, key local heaps within the OS were confined to 64K, the default text editor was confined to a segment... writing image processing tools (which I did) required special handling for all but the smallest scale workloads. These all added to developer workload and reduced system capacity in unfortunate ways. I get what you're saying that there are exceptions and hacks that make it possible to work within these limitations, but my point is that you have to care about them on 16-bit, and most of the time you really don't on 32-bit. My thesis for why that is goes back to what I was saying initially about the size of the core data types people tend to manipulate. (And this goes back to the reason I posted in the first place, which was to explain the relative difference in motivation between the 16->32 switch and the 32->64 switch.)
      - wolfgke 10y ago
        > Are you thinking of a specific concrete 16-bit architecture where it's easy to access data objects larger than 64K? Your question implies that you want one piece > 64 KiB of flat memory. With this you already stated a very strong implicit assumption about the data layout and the kind of algorithm that you want to use. My point rather is: Consider the capabilities that the 16b machine has and try to fit the data representation and algorithms that you use around it instead of wining about lack of machine capabilities. One will often find a solution using clever tricks that one would not have considered otherwise, which will often turn out to be surprisingly elegant and much better than the "naive" solution. This way to program is of course nothing for the kind of programmer that want to write an unelegant and just working program in a short amount of time, I know. :-)

by mschaef 10y ago

wolfgke 10y ago

> In a 16-bit address space (64K), you hit the 16-bit limit _all the time_. Depends on the way 16 bit is implemented. For example x86-16 uses segmented memory - enabling adressing of a little bit more (including High Memory Area) than 1 MiB of memory. The Z180 uses as far as I know a MMU (but not completely sure). Another approach that is/was in common use is to use bank switching. Depending on the kind of algorithm that you use this can make the coding much more complicated or can also be no problem, because the scheme that is used to address more memory than 2^16 bytes fits the algorithm quite natural. One interesting hack for example when coding in real mode (x86-16) that I read about is rather to use some clever sharing of bits between the segment register value and segment index: - One scheme is to consider the value of the used segment register as a pointer to a 16 byte block of memory and use the segment index to adress the specific byte in this block (with an option to increase the index "a little bit" if you want to go further) - Another scheme is to (mostly) use only the 4 highest bits of the segment register (and zero all the other ones).

mschaef 10y ago
"One scheme is to consider the value of the used segment register as a pointer to a 16 byte block of memory and use the segment index to adress the specific byte in this block (with an option to increase the index "a little bit" if you want to go further)" This only works in real mode, where the segment is shifted and directly added to the offset. In protected mode, it goes through a selector table. This can be made to work too, but it requires tiled allocations of segments with known delta between each segment. This is what __ahincr was about, if you remember it from the Win16 days.
- wolfgke 10y ago
  > This only works in real mode, where the segment is shifted and directly added to the offset. In protected mode, it goes through a selector table. Of course this is true. You wrote further above: > In a 16-bit address space (64K), you hit the 16-bit limit _all the time_. I wanted to outline that whether this is a problem or not depends a lot on the concrete 16 bit architecture.
  - mschaef 10y ago
    Are you thinking of a specific concrete 16-bit architecture where it's easy to access data objects larger than 64K? I'd be interested to hears... I really can't. Probably the most capable architecture I'm familiar with that has a native 16-bit pointer type is the 80286, which provides 24-bit physical addressing, virtualizatoin, protections, etc. Even then, at least on Windows, key local heaps within the OS were confined to 64K, the default text editor was confined to a segment... writing image processing tools (which I did) required special handling for all but the smallest scale workloads. These all added to developer workload and reduced system capacity in unfortunate ways. I get what you're saying that there are exceptions and hacks that make it possible to work within these limitations, but my point is that you have to care about them on 16-bit, and most of the time you really don't on 32-bit. My thesis for why that is goes back to what I was saying initially about the size of the core data types people tend to manipulate. (And this goes back to the reason I posted in the first place, which was to explain the relative difference in motivation between the 16->32 switch and the 32->64 switch.)
    - wolfgke 10y ago
      > Are you thinking of a specific concrete 16-bit architecture where it's easy to access data objects larger than 64K? Your question implies that you want one piece > 64 KiB of flat memory. With this you already stated a very strong implicit assumption about the data layout and the kind of algorithm that you want to use. My point rather is: Consider the capabilities that the 16b machine has and try to fit the data representation and algorithms that you use around it instead of wining about lack of machine capabilities. One will often find a solution using clever tricks that one would not have considered otherwise, which will often turn out to be surprisingly elegant and much better than the "naive" solution. This way to program is of course nothing for the kind of programmer that want to write an unelegant and just working program in a short amount of time, I know. :-)