I once developed for PC-GEOS, which wanted all memory in exactly 8K sized blocks. I wrote a set of C macros that presented an array-of-arrays as a single collection by using mod/divide operations on the index.
shrug
I've reviewed what I originally wrote and I prefer the text I published. Sure, I could review it all myself (indeed I used to) but that takes time and it was becoming a barrier to actually publishing stuff. Maybe I'd have got around to finishing it in a few months.
I don't use AI to write for me. I hate people who do that.
I kinda wish they had. 64k windows with no overlap would make segment registers a slightly inconvenient 32-bit address register.
I get why hey didn't. Someone might want to run two processes each with its own segment, but the whole machine might only have 64k in total.
Hi. I wrote it, and I'm a human. (Or at least I think I am.)
I did use an AI for spell-checking, punctuation, generally making it flow, but its all my text.
You think a machine is going to come up with "near pointers, far pointers, wherever-you-are pointers"?
1992-author (me) is wondering if he'll ever get a girlfriend.
(And I completely agree.)
Why would you ever want a single 64k object? That's like an entire machine's worth of memory!
Indeed, I say as much at the end.
But what should Intel have done? They needed a CPU that can run 8080 code but with more memory. Also it's the year ~1980 and we're limited to the technology of the age.
A system with 64k sized windows seems unavoidable.
If you extend the size of the address registers, 8080 code will only run in the first 64k, or require some kind of current window register.
An 8080 mode might have worked but that would have been expensive.
Thanks, and that POSIX link is exactly the one I expected someone to bring up.
The key point is that POSIX does not actually define a real, physical epoch, and it explicitly avoids doing so. POSIX says every day is exactly 86400 seconds, leap seconds are ignored, the relationship between POSIX time and UTC is unspecified. In other words, POSIX defines how the "time()" API behaves, not what the underlying timeline is. It’s an OS level contract, not a timekeeping standard.
The problem I’m addressing is that POSIX retroactively assumes a form of UTC that didn’t exist in 1970–1971 and it provides no authoritative mapping between POSIX time and actual UTC. That’s why you can’t use POSIX as a normative reference for "seconds since 1970". It’s not a definition of time, it’s a behavioural model for system clocks.
This document is trying to define the actual timeline that people implicitly assume when they say "Unix timestamp", in a way that’s historically honest and citable. When I was looking at a number of RFCs that use these timestamps they didn't cite this reference, but went with the wooly "Number of seconds since 1970".
I forget where I encountered it, but I've seen similar encodings that eliminated the possibility of many possible encodings for the same number by making the length part of the value.
Values 0-127 are a single byte, but if that first byte has the continuation bit set, not only does that indicate the next byte has 7 more bits to contribute, it also moves the base up to the next window.
10000000 00000000 is the only way to represent 128.
10000000 10000000 00000000 is the only way to represent 16512.
Does this encoding have a name?
Do any formats using ZIP as the underlying format use ZIP comments for metadata? Unless there's a lot of compressors leaving "Zip file generated by MySuperZipper™" then I imagine any comments left were probably done for a good reason.
True, but I wanted this to be something anyone could do with equipment they might already have lying around and also get a feel for what gravity is actually doing.
Switching on a machine that displays "9.8m/s²" isn't that much removed from looking it up in a book.
I had a similar reaction when learning 8086 assembly and finding the correct way to do `if x==y` was a CMP instruction which performed a subtraction and set only the flags. (The book had a section with all the branch instructions to use for a variety of comparison operators.) I think I spent a few minutes experimenting with XOR to see if I could fashion a compare-two-values-and-branch macro that avoided any subtraction.
It's a cookbook!
An earlier draft had a section discussing how IPv4x would work with NAT routers. Essentially, an IPv4x packet would be a UDP/IPv4 packet using a port number (84) that's been allocated to IPv4x.
Old routers would be a normal UDP packet inside a normal IPv4 and route it normally. New routers would detect UDP port 84 and treat it as an extended IPv4x packet.
I took all that out because I wasn't writing a proposal for something we should actually implement in the real world, but an alternate history "What if people who wanted IPv4 but with extra space got their way" and the story was already too long.
le sigh
Thanks though. Your comment really cheered me up.
"I bet one _could_ accelerate IPv6 deployment a lot by have a standard ..."
ahem
Yes. The router in your home would absolutely need to support IPv4x if you wanted to make use of the extended address space, just like how in the real world your home router needs to support NAT if you want to make use of shared IP.
My point is that we're still dependent on IPv4. For all the progress IPv6 has made, no-one is willing to switch IPv4 off yet. Until we do, we're still constrained by all the problems IPv4 has.
Until you would happily deploy a service on IPv6 only, I suggest that you're still dependent on IPv4.
You'd happily deploy a website for use by the general public on IPv6-only?
Your local machine isn't on the IPv4 internet if it doesn't have a globally routable IPv4 address.
Your home router that sits on the end of a single IPv4 address would need to know about IPv4x, but in this parallel world you'd buy a router that does.
If it does that's great, but why couldn't I connect to IPv6-only services back when my ISP was IPv4 only?
This wasn't a proposal, but an alternate history. The world where the people who wished for IPv4 but with extra address space get their way. By the end I come down on being happy with we're in the IPv6 world, but wishing interoperability could be slicker.
Thanks for reading and commenting everyone!
Note though that I'm not proposing IPv4x as something we should work towards now. Indeed, I come down on the side of being happy that we're in the IPv6 world instead of this alternative history.
Interesting. Who deploys and maintains the gateway?
The central idea is that a IPv4x packet is still a globally routable IPv4 packet. The extra stuff all goes in the body of the packet.
Essentially.I imagined this hypothetical happening decades ago when there were still a few /8s unallocated. I suggested that those would be set aside for IPv4x only.
"IPv6 does that."
Are you sure about that? Until a few years ago my residential ISP was IPv4 only. I definitely couldn't connect to an IPv6-only service back then.
No, in this hypothetical, routers that don't know about IPv4x will still route based on the top 32 bits of the address which is still in the same place for IPv4 packets. If your machine on your desk and the other machine across the internet both understand IPv4x, but no other machines in the middle do, you'll still get your packets across.
Could this be a the basis of an independent implementation of AmigaOS? At the moment, (I think) you still need a licensed copy of Commodore's OS to run an emulator.