Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

devblogs.microsoft.com

Post reply on HN
Print view View original

231–240 of 241 posts

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

#231

Post by 082349872349872 »

kragen wrote: post #196
082349872349872 wrote: post #80

Earlier quoted context omitted.

I once wrote a 16-bit assembler as a recursive function, which emitted code and fixed data on the way down and patched in relative offsets on the way back up. In principle, one might worry about blowing the stack, but as the sole purpose of this function was to assemble at most a half-k boot sector, in practice they fit.

i seem to recall you wrote a sort of 16-bit assembler in machine code consisting entirely of printable ascii, except for a couple of places where it had to use printable ascii instructions to modify itself to add instructions like int 21 that couldn't be done that way. but that was a different one, wasn't it?

Yes, and not an assembler but the inverse of a hex-dump.

(although that is very close to an assembler for the subset of programs consisting only of .byte foo, bar, bletch, ... directives)

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

#232

Post by kragen »

082349872349872 wrote: post #231
kragen wrote: post #196

Earlier quoted context omitted.

i seem to recall you wrote a sort of 16-bit assembler in machine code consisting entirely of printable ascii, except for a couple of places where it had to use printable ascii instructions to modify itself to add instructions like int 21 that couldn't be done that way. but that was a different one, wasn't it?

Yes, and not an assembler but the inverse of a hex-dump. (although that is very close to an assembler for the subset of programs consisting only of .byte foo, bar, bletch, ... directives)

hmm, i thought maybe that was the version where you had one- or two-byte labels for the (hexadecimal) instructions

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

#233

Post by agumonkey »

CyberDildonics wrote: post #226
agumonkey wrote: post #224

Earlier quoted context omitted.

> Says who? You didn't back this claim up with anything. Why would I need to back that up ? > No one has ever said it 'only' iterates, you hallucinated this claim. The whole point that I've made is that just because a language like haskell uses recursion for iteration, it doesn't mean iteration and recursion are the same thing or that things that iterate have anything to do with recursion. Why the mention of haskell…

Why would I need to back that up ? Why do you need to back up the things you say? Because if someone believes anything without an explanation then they don't know what's true. Why the mention of haskell all the time ? Because you wrote haskell -> foldl f z (x:xs) = foldl f (f z x) xs The original conversation was about the intellectual benefits of recursion No, you made very abstract and bizarre claims like recursion…

Asking to back things up is not asking for an explanation. You keep asking for authoritative arguments instead of discussing, it's very tense..

I just copy pasted the first line of code in wikipedia, the definition is the same in ocaml, and in spirit scheme (list pattern matching syntax aside).

You're forcing your views on me, thinking I'm defending a Haskell cult which I'm not. Most of this came before Haskell was a language name idea. Probably even back to the late 60s.

And yes inductive reasoning is about compressing the domain in a finite set of disjoint cases that "eat itself" because you can reuse other parts of that domain in substructures. Wrapping all required information as function argument makes them self sustainable / encapsulated because nothing leaks out. It's not that much of a bizarre claim.

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

#234

Post by naasking »

EnigmaFlare wrote: post #230
munificent wrote: post #185

Earlier quoted context omitted.

> That sounds awfully complicated modifying a recursive algorithm to control the recursion depth. An easy way to do it is to just pass a separate "depth" integer parameter into the recursive function. It then passes that +1 when it makes a recursive call. At the top of the function, if the depth is above your chosen limit, you bail out in some way instead of continuing to recurse. > you detect that situation and make…

OK, controlling the recursion depth just means failing more gracefully than a stack overflow. The GP's statement that nobody's likely to encounter a bigger problem is silly. It can happen walking a mesh of a 3D model where perfectly valid geometry or ordering might lead to a million-deep branch.

> The GP's statement that nobody's likely to encounter a bigger problem is silly.

I didn't actually say that, but even supposing I meant that, walking a 3D mesh in a way that requires you to keep stack context sounds like a pretty unlikely/niche scenario, so it seems even that stronger statement is true.

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

#235

Post by CyberDildonics »

agumonkey wrote: post #233
CyberDildonics wrote: post #226

Earlier quoted context omitted.

Why would I need to back that up ? Why do you need to back up the things you say? Because if someone believes anything without an explanation then they don't know what's true. Why the mention of haskell all the time ? Because you wrote haskell -> foldl f z (x:xs) = foldl f (f z x) xs The original conversation was about the intellectual benefits of recursion No, you made very abstract and bizarre claims like recursion…

Asking to back things up is not asking for an explanation. You keep asking for authoritative arguments instead of discussing, it's very tense.. I just copy pasted the first line of code in wikipedia, the definition is the same in ocaml, and in spirit scheme (list pattern matching syntax aside). You're forcing your views on me, thinking I'm defending a Haskell cult which I'm not. Most of this came before Haskell was a…

You keep asking for authoritative arguments instead of discussing,

I'm just asking for something and you haven't given anything but big claims of the benefits of recursion without any explanations or example comparisons.

And yes inductive reasoning is about compressing the domain in a finite set of disjoint cases that "eat itself" because you can reuse other parts of that domain in substructures. Wrapping all required information as function argument makes them self sustainable / encapsulated because nothing leaks out.

This is still a grandiose claim without any explanation of what it is supposed to mean, let alone any explanation of why it is true, especially in comparison to other languages. Every language has functions.

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

#236

Post by microtherion »

JoeAltmaier wrote: post #61

The old IMB 360 use a 'display' where you just chose a register by convention, pointed it at some memory then did your own linked list on call and return. In fact call was really jump-and-link(?) where you got the return address in a register. Anticipating that if your subroutine took more than a little code you'd just store it temporarily in your allocated 'display'. No push/pop at all! Unless you wanted to write it…

Jump and Link also carried over to POWER and PowerPC

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

#237

Post by EnigmaFlare »

naasking wrote: post #234
EnigmaFlare wrote: post #230

Earlier quoted context omitted.

OK, controlling the recursion depth just means failing more gracefully than a stack overflow. The GP's statement that nobody's likely to encounter a bigger problem is silly. It can happen walking a mesh of a 3D model where perfectly valid geometry or ordering might lead to a million-deep branch.

> The GP's statement that nobody's likely to encounter a bigger problem is silly. I didn't actually say that, but even supposing I meant that, walking a 3D mesh in a way that requires you to keep stack context sounds like a pretty unlikely/niche scenario, so it seems even that stronger statement is true.

I must have misunderstood your "Stack growth is just something you don't have to worry about for almost all scenarios you're likely to encounter.".

It's fairly intuitive to walk a mesh recursively by following adjacent edges and you have to keep track of where you've been which means storing a lot of data somewhere. Maybe there are better algorithms but sometimes you just reach for what's most obvious. I suppose there are many analogous applications of traversing a graph structure.

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

#238

Post by 082349872349872 »

kragen wrote: post #232
082349872349872 wrote: post #231

Earlier quoted context omitted.

Yes, and not an assembler but the inverse of a hex-dump. (although that is very close to an assembler for the subset of programs consisting only of .byte foo, bar, bletch, ... directives)

hmm, i thought maybe that was the version where you had one- or two-byte labels for the (hexadecimal) instructions

Oh yeah, I'd forgotten about that one! hmm...

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

#240

Post by Tabular-Iceberg »

taeric wrote: post #186
Tabular-Iceberg wrote: post #174

Earlier quoted context omitted.

Cooperative multitasking is in fashion now, so we might get a whole new generation to take over. Or they’ll just cargo-cult everything and have no clue what’s happening under the hood.

To be fair, I doubt I fully understand what is going on fully under the hood. I usually bring this line up when folks lament that we don't have abstractions that fits the instruction set of the computer. Ignoring that many of the abstractions of the computer are orthogonal to isolated instructions, at this point. https://stackoverflow.com/questions/72423227/is-a-schedulabl... was a fun read as I was looking for somet…

There can be degrees of understanding. What I’ve been seeing is devs deciding that everything should be async to improve performance, but then running every single task in its own event loop, making it exactly as synchronous as before, but with more overhead.
Post reply on HN