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

101–110 of 241 posts

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

#101

Post by parlortricks »

howerj wrote: 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 came across your works learning and consuming all things Forth and Subleq. It was great to read over how you approach things. I wanted to purchase your book but Amazon says no...will there be another run?

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

#102

Post by dnedic »

greesil wrote: post #78

It's not ancient if you still do embedded development

It really depends on what you classify under embedded. Everything more expensive than a Padauk or newer than PIC will have hardware support for the stack, and also most likely have the heap provided by newlib.

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

#103

Post by billforsternz »

HeyLaughingBoy wrote: post #77

A long time ago (1991 maybe?) one of my first freelance projects during my first job out of college was to design an RS232 serial multiplexer -- take an incoming serial datastream, parse it, and redirect it to one of n outputs based on its header. I remember doing something similar to what he describes. My hardware design was basically a Z80, a 2716 EPROM (I may have also had a Parallax EPROM emulator to speed debugg…

That is very cool and I say that as someone whose first project in my first job (1982) was to write the code for a serial multiplexer with a Z80, a 2716 EPROM, Zilog SIOs (or maybe DUARTs actually).... and 2K of static RAM. I basically learned my craft on the job and there's no way I could have done it without the RAM. A few years later I would have relished the challenge. Although you are really limiting the complexity of the protocol you can deal with ... (perhaps not such a terrible thing:).

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

#104

Post by smcin »

HeyLaughingBoy wrote: post #77

A long time ago (1991 maybe?) one of my first freelance projects during my first job out of college was to design an RS232 serial multiplexer -- take an incoming serial datastream, parse it, and redirect it to one of n outputs based on its header. I remember doing something similar to what he describes. My hardware design was basically a Z80, a 2716 EPROM (I may have also had a Parallax EPROM emulator to speed debugg…

'2716 EPROM' was a 16K (2kb x 8) EPROM.

Which customer/sector was your project intended for?

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

#105

Post by mywittyname »

deckard1 wrote: post #38
kstrauser wrote: post #20

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…

Imagine using a program that can only allocate 4GB of ram because it has 32-bit address space. There's no benefit to that limitation, it's an arbitrary limit imposed by the trades-offs made in the 80s. It just means that someone will need to build another layer to their program to chunk their input data then recombine the output. It's a needless waste of resources.

The benefit of not having a limitation is that the real limits scale with compute power. If you need more than 4GB of memory to process something, add more memory to the computer.

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

#106

Post by mytailorisrich »

smcin wrote: post #104
HeyLaughingBoy wrote: post #77

A long time ago (1991 maybe?) one of my first freelance projects during my first job out of college was to design an RS232 serial multiplexer -- take an incoming serial datastream, parse it, and redirect it to one of n outputs based on its header. I remember doing something similar to what he describes. My hardware design was basically a Z80, a 2716 EPROM (I may have also had a Parallax EPROM emulator to speed debugg…

'2716 EPROM' was a 16K (2kb x 8) EPROM. Which customer/sector was your project intended for?

Yes, the xx(x) number in the 27xx(x) EPROM series indicates the kilo (1024) bits. So indeed this is 2 KiB. This sounds OK for the application described, especially as it was no doubt written in assembly and obviously bare metal. When it does not fit but not far off it's when the fun of code optimisation kicks in ;)

Edit: Very interesting how easily available they still seem to be according to Google.

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

#107

Post by Joel_Mckay »

munificent wrote: post #96
mannyv wrote: post #71

Earlier quoted context omitted.

Recursion in production code is bad news, because you can't control the depth of your call tree. At some point you will crash because the runtime won't be able to allocate any more stack. And you can't preflight it because if you could preflight it you wouldn't be doing recursion. Recursion is a nice toy, but in real life it's a ticking time bomb.

This is just bananas. I work in programming languages. I currently have open in my editor a code formatter that I maintain that uses at least half a dozen recursive algorithms to traverse syntax trees and other data structures. This program is used by almost every user of our language, invoked on every save, and probably executed billions of times a day. Recursion is fine .

"Recursion is fine [for your use-case]."

In general it is naive, often dangerous, and an inefficient space/time trade-off.

I have been writing software for several decades... does that make one less insightful or more biased?

https://youtu.be/pmu5sRIizdw?feature=shared&t=31

=)

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

#108

Post by CyberDildonics »

samatman wrote: post #74
CyberDildonics wrote: post #68

Earlier quoted context omitted.

I agree. People love making things clever instead of making things done. Recursion for iteration is just more complicated iteration. I've never seen a good argument for it in modern programming, it just ends up being the classic backwards rationalization of something people want to believe. Recursion for traversing a tree is just using the call stack as a stack data structure. Any balanced tree is never going to exce…

The same argument suggests that a recursive stack traversal will never consume more than 64 stack frames, so consuming stack frames is no reason not to use a recursive function. It's just as easy to limit recursion depth, if you need to, just pass along a counter and check it. I haven't found that hand-rolling a second stack, instead of using the program stack, is easier to debug, the opposite if anything, but your m…

so consuming stack frames is no reason not to use a recursive function.

Saving stack memory isn't the point (even though a static array definitely does, because instead of multiple pointers and variables on the stack it only would have to store the node index of a tree).

The point is that you can see the whole stack and all the data that you're using at one time in a debugger instead of trying switch through call stacks to find data.

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

#109

Post by howerj »

parlortricks wrote: post #101
howerj wrote: 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 came across your works learning and consuming all things Forth and Subleq. It was great to read over how you approach things. I wanted to purchase your book but Amazon says no...will there be another run?

Thanks! You should still be able buy it, you might have to either click on "Paperback" or "Hardcover", if you want to get the kindle edition you have to go to the Amazon webpage that serves you country (e.g. if you are in the UK and you are on amazon.com you get "This title is not currently available for purchase", but if you go to amazon.co.uk, you get buy it). That's an odd user interface issue...

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

#110

Post by [deleted] »

HeyLaughingBoy wrote: post #77

A long time ago (1991 maybe?) one of my first freelance projects during my first job out of college was to design an RS232 serial multiplexer -- take an incoming serial datastream, parse it, and redirect it to one of n outputs based on its header. I remember doing something similar to what he describes. My hardware design was basically a Z80, a 2716 EPROM (I may have also had a Parallax EPROM emulator to speed debugg…

[deleted]
Post reply on HN