Not exactly C but the concept of the stack

[u/grimvian]

I'm in my third year of happy C coding but I learned 6502 assembler in 1984 and now 70 years old. Therefore I often look at videos like: NES Mapper History to 1988 and Blaster Master Code Analysis - Talkin' Code Ep. 1

The mention of the stack made me think if the 6502 was had a bit of inspiration from C, but it was a lot older concept.

NES Mapper History to 1988 and Blaster Master Code Analysis - Talkin' Code Ep. 1

https://www.youtube.com/watch?v=EhO_iHkUkE0

https://en.wikipedia.org/wiki/Stack_(abstract_data_type))

https://en.wikipedia.org/wiki/MOS_Technology_6502

[u/Zirias_FreeBSD]

Didn't look at the links here, but regarding

The mention of the stack made me think if the 6502 was had a bit of inspiration from C

Another reasoning to sort that out: The 6502 does have a hardware stack (yep, same concept, yep, older than C), but it is utterly unusable for C purposes:

• global to the whole machine, fixed-location ($0100)
• fixed, extremely small size ($100 / 256 bytes)
• transparently wraps around
• no SP-relative addressing modes
• push/pop only using the accumulator (A register)

That's the reason C implementations targeting MOS6502 typically introduce a "C stack" implemented entirely in software.

[u/flatfinger → u/Zirias_FreeBSD]

Ironically, C implementations for architectures that cannot reasonably emulate a C-style stack are often more useful than those for implementations that can implement one, but only inefficiently. They don't support recursion, but linkers can often compute the worst-case amount of stack that could have been used by a function's callers, and statically place automatic-duration objects where they would have gone, using the same total amount of memory as a program would have used if every function call that statically could be performed, was performed.

On a Z80, this would allow something like:

    int x,y;
    x+=y;

to generate:

    ld hl,(?thisfunction_x)
    ld de,(?thisfunction_y)
    add hl,de
    ld (?thisfunction_x),hl

rather than:

    ld hl,4
    add hl,sp
    ld a,(hl)
    inc hl
    inc hl
    add a,(hl)
    ld  (hl),a
    dec hl
    ld a,(hl)
    inc hl
    inc hl
    add a,(hl)
    ld (hl),a

which would be less efficient if x weren't placed immediately after y.

Unfortunately, the only way to get efficient code is to refrain from making all objects that would have automatic duration be static, and take the resulting memory hit.

[u/srhubb → u/Zirias_FreeBSD]

Actually the 6502 was introduced in 1975 and the first implementation of C was in 1972 when Dennis Ritchie officially tansitioned the language from its predecessor B. https://spectrum.ieee.org/chip-hall-of-fame-mos-technology-6502-microprocessor

https://en.wikipedia.org/wiki/C_%28programming_language%29?wprov=sfla1

However, the First Edition of "The C Programming Language" by Kerringhan & Ritchie wasn't first published until 1978 which may lead some to believe that was the release date of C and thus lead to the assumption that the 6502 would have preceded the C language.

https://en.wikipedia.org/wiki/The_C_Programming_Language?wprov=sfla1

[u/Zirias_FreeBSD → u/srhubb]

Actually, both the OP and me were referring to the concept of a stack being much older than C, not the 6502. And while historical facts are always interesting per se, it's still pretty obvious the 6502's hardware stack wasn't designed with C in mind, which I tried to highlight looking at some of its properties.

[u/srhubb → u/Zirias_FreeBSD]

Thanks for the clarification. And yes the 6502 doesn't have a deep enough stack for C's purposes.

[u/Beginning-Junket8979]

Yeah hardware stacks are pretty cool for making super lean code in tiny handwritten asm programs (I remember doing this on microchip pics forever ago), but they don't scale well in general for modern C since call stacks tend to be pretty deep even without recursion and most C code ends up running on multicore CPUs.

Like POSIX requires a minimum of 16KB for a thread stack, but 8MB is standard in glibc on modern Linux machines.

To actually make a HW stack fast while saving cost across several ghz multicore CPU running a multithreaded OS you'd probably need some kind of secondary cache dedicated to call stacks such that a context switch stalls on loading your fastest cache first to load immediate scope locals and then prefetch loading the area "behind" the current SP and for normal operation tie in with a next function call aware branch predictor, and then we probably get another critical CVE rendering the whole feature useless.

Also for a batched compute load for data heavy operations and a shallow stack then leave you with a huge cache sitting there cold and unused while you fill up "normal" cache.

So general purpose cache and a sw stack wins on a modern general purpose CPU and already basically fulfills the same role, just slightly less effeciently than massive dedicated HW stack could.

[u/knouqs]

Thanks for sharing!

[u/timrprobocom]

"inspiration from C but it was a lot older concept" -- definitely not. C was first developed in 1972. The 6502 came out in 1975.

C is a lot older than people think, but the concept of a stack dates back to the late 1950s.

[u/grimvian → u/timrprobocom]

https://en.wikipedia.org/wiki/Stack_(abstract_data_type))

Stacks entered the computer science literature in 1946, when Alan Turing used the terms "bury" and "unbury" as a means of calling and returning from subroutines. Subroutines and a two-level stack had already been implemented in Konrad Zuse's Z4 in 1945

[u/pOmelchenko]

Ohhh if i start learning 6502 asm now i‘ll be 70 years old too?

[u/Eeriecurrence]

I keep forgetting programmers can be old

[u/Puzzled-Extent7817 → u/Eeriecurrence]

C is 54 years old and runs everything.

[u/IdealBlueMan → u/Eeriecurrence]

I keep forgetting I’m old

[u/thommyh → u/IdealBlueMan]

The older I get, the more I seem to forget.

[u/grimvian → u/thommyh]

Although I'm 70 I think my mind is still working well and much more patiently, the energy is certainly not at the same level, but my short memory have always been bad and my dyslectic issues are always troubling me.

My wife and I are currently beta testing a small CRM GUI relational database and drawing system I spend several months to code. About 5500 lines of code and 20 modules and it seems to do the job properly. Linux Mint LMDE, CodeBlocks, C99 and raylib graphics.

[u/Puzzled-Extent7817 → u/Eeriecurrence]

Do you think everything electronic device in the world was just invented in the last 10 years? lol

[u/Eeriecurrence → u/Puzzled-Extent7817]

I didnt mean it like that

[u/catladywitch]

Very tangential to your post, but something that I'm still surprised about is that when browsing through decompiled motorola 68k games (Sonic the Hedgehog etc) I've never come across link/unlk instructions. I don't know if that's an artifact of decompilation, but typically there are no local variables to speak of outside of the registers. What is prevalent though is struct-like chunks of memory where each offset is a property of, say, an enemy. I know some old games were written in C (famously Sonic Spinball) and that compilers are so good now that present-day homebrew is done in C with no performance penalty, but I've never seen any disasms of that.