6 ms·

Another 68000 system time related bug but completely different problem (former Apollo/Domain sysadmin here, which I became at one company because I was already

Another 68000 system time related bug but completely different problem (former Apollo/Domain sysadmin here, which I became at one company because I was already doing their Unix sysadmin job. We had to periodically reset the system clocks on those): ''The bug apparently results from the high 32 bits of the clock data type being declared as a 31 bit value instead of 32 bit in the pascal include files. The reason for this is lost to history, but early pascal compilers may have had problems with 32 bit unsigned numbers, possibly because the early Motorola 68000 processor chips didn't have 32 bit unsigned multiply operations.'' https://jim.rees.org/apollo-archive/date-bug https://jim.rees.org/apollo-archive/date-bug

tpmx 4y ago
Do I understand this correctly - it was a 31-bit version of the 32-bit Y2K38 problem?
- xxpor 4y ago
  The year 2038 problem is a 31 bit problem: time_t is signed (in POSIX).
  - tpmx 4y ago
    So, was it a 30-bit problem?
    - KMag 4y ago
      It looks like maybe Apollo/Domain systems use an epoch of 1929-10-14 instead of 1970-01-01. Maybe that's the birthday of one of the early developers (or their spouse). There's nothing particularly magical about the Unix epoch.
      - toast0 4y ago
        > There's nothing particularly magical about the Unix epoch. It's the beginning of time, everything before is Omphalos; even the Omphalos conjecture itself; Unix is meta like that.
      - owl57 4y ago
        > There's nothing particularly magical about the Unix epoch. When you have to debug the same event reported in five different timezones, and then see some ugly 13-digit numbers and immediately know that's milliseconds since a certain globally-coherent moment… That moment definitely starts to feel magic.
      - cf100clunk 4y ago
        > 1929-10-14 Hmmm, about 2 weeks before the Wall Street Crash of 1929, so I doubt it refers specifically to that.
mikepavone 4y ago
> possibly because the early Motorola 68000 processor chips didn't have 32 bit unsigned multiply operations. This doesn't really make sense as an explanation. For both signed and unsigned multiply, the 68000 has a 16x16 -> 32 multiply. This is indeed kind of inconvenient if you need to multiply 32-bit numbers, but 31-bit numbers are not any easier. If anything, the unsigned cases is easier to reason about than the signed one
- lokedhs 4y ago
  Not only that, the M68k has the mulu.l instruction which is an unsigned 32-bit multiplication instruction. Go it has all the instructions you need.
  - mikepavone 4y ago
    The 68000 lacks that instruction. It was added in the 68020.

tpmx 4y ago

Do I understand this correctly - it was a 31-bit version of the 32-bit Y2K38 problem?

xxpor 4y ago
The year 2038 problem is a 31 bit problem: time_t is signed (in POSIX).
- tpmx 4y ago
  So, was it a 30-bit problem?
  - KMag 4y ago
    It looks like maybe Apollo/Domain systems use an epoch of 1929-10-14 instead of 1970-01-01. Maybe that's the birthday of one of the early developers (or their spouse). There's nothing particularly magical about the Unix epoch.
    - toast0 4y ago
      > There's nothing particularly magical about the Unix epoch. It's the beginning of time, everything before is Omphalos; even the Omphalos conjecture itself; Unix is meta like that.
    - owl57 4y ago
      > There's nothing particularly magical about the Unix epoch. When you have to debug the same event reported in five different timezones, and then see some ugly 13-digit numbers and immediately know that's milliseconds since a certain globally-coherent moment… That moment definitely starts to feel magic.
    - cf100clunk 4y ago
      > 1929-10-14 Hmmm, about 2 weeks before the Wall Street Crash of 1929, so I doubt it refers specifically to that.

mikepavone 4y ago

> possibly because the early Motorola 68000 processor chips didn't have 32 bit unsigned multiply operations. This doesn't really make sense as an explanation. For both signed and unsigned multiply, the 68000 has a 16x16 -> 32 multiply. This is indeed kind of inconvenient if you need to multiply 32-bit numbers, but 31-bit numbers are not any easier. If anything, the unsigned cases is easier to reason about than the signed one

lokedhs 4y ago
Not only that, the M68k has the mulu.l instruction which is an unsigned 32-bit multiplication instruction. Go it has all the instructions you need.
- mikepavone 4y ago
  The 68000 lacks that instruction. It was added in the 68020.