More

winocm · 2025-11-29T09:36:38 1764408998

Kinda sorts. The systems that the "MacOS on CHRP" thing ran on had a very strange looking device tree, with some bizarre combination of PC and Mac peripherals.

  Apple Cobra Open Firmware CHRP 1.1 B3 built on 08/18/97 at 13:04:24
  Copyright Apple Computer 1994,1996,1997
  Copyright IBM Corporation 1996
  All rights reserved.
   ok
  0 > dev / ls 
  ff82ec18: /cpus
  ff82ee08:   /PowerPC,604e@0
  ff82f600: /chosen
  ff82f750: /memory@0
  ff82f8d8: /memory-controller@fec00000
  ff82f9d8: /openprom
  ff82fab8: /rom@ff000000
  ff82ff48:   /boot-rom@fff00000
  ff830060: /options
  ff830828: /aliases
  ff830c78: /packages
  ff830d00:   /deblocker
  ff8314c8:   /disk-label
  ff832090:   /obp-tftp
  ff835db8:   /mac-parts
  ff836578:   /mac-files
  ff837de0:   /fat-files
  ff839700:   /iso-9660-files
  ff83a148:   /bootinfo-loader
  ff83b7d0:   /xcoff-loader
  ff83c060:   /pe-loader
  ff83c7d0:   /elf-loader
  ff83da18:   /terminal-emulator
  ff83dab0: /rtas
  ff83dc70: /pci@80000000
  ff83ff38:   /isa@b
  ff8414e0:     /nvram@i74
  ff841ad0:     /rtc@i70
  ff842500:     /parallel@i378
  ff842988:     /serial@i3f8
  ff843020:     /serial@i2f8
  ff8436b8:     /sound@i534
  ff850288:     /8042@i60
  ff8515f8:       /keyboard@0
  ff854b88:       /mouse@1
  ff8554c0:     /fdc@i3f0
  ff858730:       /disk@1
  ff85bac0:     /op-panel@i808
  ff85bba0:     /pwr-mgmt@i82a
  ff85bed8:     /timer@i40
  ff85c070:     /interrupt-controller@i20
  ff85c250:     /dma-controller@i0
  ff85c738:   /pci-ide@b,1
  ff85d028:     /ide@0
  ff85db78:     /ide@1
  ff85e6c8:       /cdrom@0
  ff862e60:   /mac-io@d
  ff863468:     /scsi@10000
  ff865298:       /disk
  ff8660c8:       /tape
  ff8671b8:     /adb@11000
  ff867cb0:       /keyboard@2
  ff8685a0:       /mouse@3
  ff8687c0:     /escc-legacy@12000
  ff8689b8:       /ch-a@12002
  ff868b08:       /ch-b@12000
  ff868c58:     /escc@13000
  ff868e40:       /ch-a@13020
  ff869500:       /ch-b@13000
  ff869bc0:     /via@16000
  ff869cb0:     /interrupt-controller@40000
  ff869e70:   /cirrus@e
  ff86e2c8:   /pci1022,2000@f
   ok
  0 >

Refer to the "Macintosh Technology in the Common Hardware Reference Platform" book for more information, if you're curious about the Mac IO pieces.

The Motorola Yellowknife board seems remarkably similar to this system, as well as the IBM Long Trail system (albeit with Long Trail using a VLSI Golden Gate versus a MPC106 memory controller). Both of them use W83C553 southbridges and PC87307 Super I/O controllers.

The architecture is kind of weird, but the schematics on NXP's website can probably elucidate a bit more on the system's design.

winocm · 2025-11-06T06:57:57 1762412277

Mildly related, sort of, one can prevent expansion of variadic macros as follows:

   #define printf(...)

   int (printf)(const char *, ...);

I keep on seeing many random code bases just resort to #undef instead...

pwdisswordfishy · 2025-11-06T08:32:39 1762417959

Doesn't this trigger warnings?

joriatsy · 2025-11-06T10:15:34 1762424134

Function like macros literally requires name( , i.e name followed directly by open paren, otherwise no macro substitution occurs. so (name)() will always suppress function like macros (but not non-function ones, i.e regular #define name xxx)

winocm · 2025-09-25T18:38:20 1758825500

You also get "Program Files (ARM)" (including a complementary "SysArm32") on older arm64 systems too.

winocm · 2025-08-14T21:38:18 1755207498

If you want to download SARS-CoV-2, here you go: https://www.ncbi.nlm.nih.gov/nuccore/NC_045512.2

winocm · 2025-08-07T23:14:29 1754608469

The latter is known as a "twiddle" in BSD land.

(c.f: https://ftp.netbsd.org/pub/NetBSD/NetBSD-release-10/src/sys/...)

winocm · 2025-08-06T22:28:32 1754519312

At least since maybe the DEC Alpha 21264. It could address 48-bits of VA space, but that comes with caveats due to PALcode specific intricacies.

I think VMS (or was it Tru64?) uses this mode, but many other OSes just use 43-bit or 40-bit addressing. Realistically though, I don’t think many users would be using workloads that addressed more than 38-bits worth of contiguous VA space in 1998-1999.

winocm · 2025-07-26T18:32:00 1753554720

LLVM SPIR-V's backend is a bit... questionable when it comes to code generation.

winocm · 2025-06-30T23:01:40 1751324500

Don't forget the infamous pattern used in some C projects too:

  struct foo decl = {
    .member = /* ... */
    .next = &(struct nested_pointer) {
        .nested_member = /* ... */,
    },
    .array = (struct nested_array[]) {
      [0] = { /* ... */ },
    }
  };

This pattern does not work in C++ as the nested declarations become temporaries.

winocm · 2025-06-16T01:43:36 1750038216

Consider this implementation:

https://llvm.org/doxygen/STLFunctionalExtras_8h_source.html

winocm · 2025-03-24T05:12:24 1742793144

Kind of. NIR is more oriented towards lowering and optimizing code for driver backends, as far as I know. SPIR-V is targeted towards the other end of the spectrum.