3 ms·

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'

by 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. :-)
- mschaef 10y ago
  > Consider the capabilities that the 16b machine ...instead of wining about lack of machine capabilities. ...the kind of programmer that want to write an unelegant and just working program in a short amount of time, I do hear you, but one of the things I love about virtually all modern hardware is just how much capability it puts within the reach of totally naive and quick development strategies. If I can inelegantly solve two or three problems in the same time I can elegantly solve one, then that strikes me as a net win (at least for the people that need problems solved more than code written.) I don't mind pushing the hardware and searching for elegance, but I'd rather be forced into it by the necessities of the problem I'm trying to solve.

by mschaef 10y ago

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. :-)

mschaef 10y ago
> Consider the capabilities that the 16b machine ...instead of wining about lack of machine capabilities. ...the kind of programmer that want to write an unelegant and just working program in a short amount of time, I do hear you, but one of the things I love about virtually all modern hardware is just how much capability it puts within the reach of totally naive and quick development strategies. If I can inelegantly solve two or three problems in the same time I can elegantly solve one, then that strikes me as a net win (at least for the people that need problems solved more than code written.) I don't mind pushing the hardware and searching for elegance, but I'd rather be forced into it by the necessities of the problem I'm trying to solve.