Live data from Hacker News

Subroutine calls in the ancient world, before computers had stacks or heaps

devblogs.microsoft.com

41–50 of 241 posts

Re: Subroutine calls in the ancient world, before computers had stacks or heaps

#41
And to think that's where we come from. The Intel 8008, the ancestor of the x86 processor family, just has a 7-level call hardware stack only used by the unconditional and conditional call and return instructions. So, there is no push and pop instructions. As the only way to access a byte in memory was to store the address in the HL register pair (no absolute addressing mode) before the load or store instruction and as there was no way to disable hardware interrupts, it was almost impossible to write useful interrupt routines without some external hardware trick.

Re: Subroutine calls in the ancient world, before computers had stacks or heaps

#42

Earlier quoted context omitted.

Historically, that was also a big goal of GNU. It aimed to get rid of artificial limitations in core utilities. That was a big improvement over (made up example) sed having a finite and short maximum command length.

I can understand why people wanted that, and the benefit of doing that. With that said, I also see benefit in having limitations. There is a certain comfort in knowing what a tool can do and cannot do. A hammer cannot become a screwdriver. And that's fine because you can then decide to use a screwdriver. You're capable of selection. Take PostgreSQL. How many devs today know when it's the right solution? When should t…

> A hammer cannot become a screwdriver.

Don't tell me you've never hammered a screw into a wooden plank? Vice versa, a screwdriver also can be used as a hammer although a quite pathetic one.

Re: Subroutine calls in the ancient world, before computers had stacks or heaps

#43
For the kind of programs I write for AVR-8 it seems insane to use the calling conventions of C, so if I write assembly I can sometimes keep the inner loop variables in registers (big register file) and otherwise use the methods he describes. I like “coloring” functions in an app like that, if I know a red and a green function will never be active at once I can reuse locals/parameters for them.

Re: Subroutine calls in the ancient world, before computers had stacks or heaps

#44

Earlier quoted context omitted.

Most recursion is about as bad as goto coding methodologies. Personally, I think it should be avoided in modern compiled languages too. Haskell is fun to play around on, but it is horrific to consider using in a stable production environment. =)

Outside of a university course, if I see recursion in a non-FP language I consider it a code-smell

Recursion is like an inductive proof, you can show it is correct and it normally fits on half of a small screen.

Re: Subroutine calls in the ancient world, before computers had stacks or heaps

#45
post #7

Am I the only one who read it as the ancient world before computers existed had stacks or heaps? English is so weird sometimes...

This has nothing to do with English, it's just syntactic ambiguity. Every language has it.

Re: Subroutine calls in the ancient world, before computers had stacks or heaps

#46
post #7

Am I the only one who read it as the ancient world before computers existed had stacks or heaps? English is so weird sometimes...

Yeah, I was all ready to learn about how the ancient Egyptians used stacks to build the pyramids or something.

Technically they did.

Re: Subroutine calls in the ancient world, before computers had stacks or heaps

#47
post #15

I wrote a Forth interpreter for a SUBLEQ machine ( https://github.com/howerj/subleq ), and for a bit-serial machine ( https://github.com/howerj/bit-serial ), both of which do not have a function call stack which is a requirement of Forth. SUBLEQ also does not allow indirect loading and stores as well and requires self-modifying code to do anything non-trivial. The approach I took for both machines was to build a virt…

I was about to talk about subleq, but it's damn difficult even to write a "Hello world".

Re: Subroutine calls in the ancient world, before computers had stacks or heaps

#48
post #7

Am I the only one who read it as the ancient world before computers existed had stacks or heaps? English is so weird sometimes...

The ordinarily “The Ancient World” means an era ending with the fall of the Western Roman Empire circa 476 CE. All that world was well before computers were a thing (even the human type were called “scribes,” “clerks” etc.) So of course I read it the same way even though “before computers” was redundant once your comment made me think about it.

They had abaci with stacks.

Re: Subroutine calls in the ancient world, before computers had stacks or heaps

#49

For the kind of programs I write for AVR-8 it seems insane to use the calling conventions of C, so if I write assembly I can sometimes keep the inner loop variables in registers (big register file) and otherwise use the methods he describes. I like “coloring” functions in an app like that, if I know a red and a green function will never be active at once I can reuse locals/parameters for them.

Yes, C's stack usage can be unintuitive when working in a constrained environment, especially when accustomed to the affordances of desktop operating system. I once joined a project where several developers had spent a couple weeks trying to track really hard to pin down bugs in several subsystems they were developing in a microcontroller codebase. They would move things around and the bugs would move. After tracing things a bit and setting a trap, I found the places in the codebase where the call stack got too deep and was scribbling over other data structures.

Re: Subroutine calls in the ancient world, before computers had stacks or heaps

#50

Note that before we had arbitrarily extensible heaps, programmers always did at least a little engineering, in that they had to consider the probable distribution of inputs and size* all their intermediate storage appropriately. * giving rise to "BUGS AND LIMITATIONS "

Really, the mistake was letting humans provide input to computer programs.
Post reply on HN