[hvs]

It's amazed me that the first 50 years of computers were "this is how to structure memory for operating systems" and the next 30 have been "hackers take advantage of all of that so we need to do a bunch of convoluted stuff just to try to thwart them." Kind of unfortunate that so much energy has to be spent on this work, but I appreciate that it is.

[rini17]

no actually after 50 years of "how to shoehorn memory into something C can use" we reap the rewards

[pnm45678]

perhaps it's time we stopped shoehorning memory to fit C and just used more memory-safe languages?

[anthk]

Multics had both. It's the Unix inspiration. Imagine something more secure and with a better hardware design than Unix.

[ogogmad]

I'm wondering what an alternative model would look like, not oriented towards C.

[gumby]

Some real world examples I have used:

Harvard architecture machines (which are not uncommon in microcontrollers)

Segmented memory, or any non-flat memory

Addressable memory with non-uniform access time (cache doesn't count because cache lines can't be addressed directly)

Address spaces not a factor of 2. Variable byte sizes ("byte" did not mean "8 bits" until the 360, and even in those days, just in the IBM world)

Word length larger than address length.

Some hardware-tagged architectures.

Machines with hardware-supported transporting GCs.

Different regions of memory that are architecturally distinct (shared memory with machines of different architectures, which these days can mean GPUs).

And one I haven't used yet:

distributed-computation-in-RAM

[DougMerritt]

One alternative CPU model were the various Lisp machines.

A really amazing example, though, was Intel's first 32 bit CPU, the iAPX 432 [1] -- it was actually object oriented. And it supported garbage collection (like Lisp machines).

It was kind of beautiful from one point of view, but it was absurdly impractical and complicated and slow. It was an extreme example of CISC, and the (simple and fast) RISC revolution killed off such things. Well, the iAPX killed itself, but...

[1] https://en.wikipedia.org/wiki/Intel_iAPX_432

[loeg]

Some of the 8-bit micros without many general purpose registers are relatively C unfriendly.

[DougMerritt]

Ok, but they're not friendly to anything but assembler.

Well, since they typically have memory that cycles in the ballpark of instruction cycle times (unlike desktop and server CPUs where there's two orders of magnitude difference), that's friendly to Forth I suppose. But that is a small minority of usage even in those environments. It's more like Forth is friendly to slow architectures. :)

[rsaxvc]

I've seen even those forced to C, with such gems I've run into like:

Link-time stack resolution(and aliased even, so pretty good density)

Default int is char. Please use short or ANSI int.(because 16-bit int would be painfully slow)

Recursion is not supported in this memory model(because the stack is resolved at link time, so...)

Function pointers must be compile-time resolvable(I think this machine didn't have a way to represent program counter values in GPRs/variable jumps)

"Function prototypes are an ANSI feature"(part of compiler the front-end also used on a bunch of UNIX box compilers).

[DougMerritt]

Wow. Have you got a link? I hadn't heard about that. That's kind of a mind blowing list.

[rsaxvc]

I think most of these solutions probably predate 8051 and ST7 cores(which both have stack pointers) where I ran into them but reduced memory models are still pretty useful for them, due to the overhead vs RAM usually fitted. It's too late to edit my comment. I'll mostly discuss the fallout from static stack variable allocation.

From https://www.st.com/resource/en/user_manual/um0015-st7-8bit-m... (8.3.5 Limitations put on the full implementation of C language)(I think this is talking about Hicross C, but COSMIC and Raisonance work the same depending on stack memory model): The ST7 family provides a limited RAM size, of which the stack takes only a part, that can be as small as 64 bytes. This does not allow the use of the stack for parameter passing. Thus, the implementation of C for the ST7 uses registers and a few memory locations to pass the parameters, and allocates local variables to RAM just like global variables. This works the same way as in a typical implementation, but with the following restrictions...

You can still get an evaluation copy of COSMIC C and try this out. Here I made a function call itself void port_init(void){port_init();}. Note that this error comes from the linker, clnk, not the compiler, because the linker is responsible for stack allocation globally, as described above): #error clnk vumeter.lkf:1 function _port_init is recursive.

There's a similar error if you call a function from anything called from main() and also from any interrupt entry point. This is because the memory model isn't re-entrant, so calling the same function from >1 path can cause them to overlap, corrupting their staticly allocated variables.

https://www.cosmicsoftware.com/pdf/RX.pdf has an explanation for "is recursive" and "is reentrant".

COMSIC C will also let you compile enum {x = x}, but I don't know what value x gets.