"Most CPUs implement CALL and RETURN opcodes. These instructions were originally meant for sharing common bits of code"
Dear Paul, are you referring to GOSUB/RETURN statements in the BASIC language? These instructions permit to call a piece of code multiple times during the execution of the program. The called section is enclosed between a label and the RETURN instruction, but it has access to all the variables declared in the main section of the program. The code section called by GOSUB behaves like a subroutine without any input parameters, neither local variables. The GOSUB/RETURN couple is a very primitive version of CALL/RETURN paradigm.
GOSUB has subroutine semantics. I was referring to CPU opcodes for implementing subroutines. I know these opcodes as CALL and RET, although they were given different names in earlier CPUs. Claude says that EDSAC (1949) is often cited as the first practical implementation of subroutines.
Thanks for your answer! Sorry for my question: it was not clear. You argue (in many your posts) the CALL/RETURN statements where invented for subroutines, not for implementing functions. Are you referring to the simplest form of subroutine? I mean a subroutine with the following features:
_ no input/output parameters.
_ full access to global variables.
_ all local variables are static (they are allocated when the program is loaded, their values are kept between the subroutines calls).
This type of subroutine does not require a call stack.
One example of this simplest form of subroutine is the GOSUB/RETURN couple of statements in Basic.
Another example is a subroutine in Fortran 77 and earlier versions:
_ all local variables are static.
_ all parameters are passed to the called subroutine by address.
For this reasons, Fortran 77 and earlier versions have not a call stack.
Nice post. I think this one does the clearest job of pointing out that what most programmers think of as the fundamental building blocks of software -- functions -- are in fact not fundamental at all.
> What is called “programming” today is not programming of bare CPUs, but, is only a function-based variant of programming that requires function-based engines and libraries. This is what we have. We’re not going to go back to square one and start all over. We have to build on what we have.
Speak for yourself :-D . In 3 years we'll be using LLMs to write entire operating systems with exactly the features we say we want, and no more. Those OSes will be written in whatever programming language we tell it to use, including momentarily-imaginary ones we prompt into existence.
Question: Do we need to rewrite the stack or simply to realize that the current stack cannot address the new set of problems? Maybe, like in 1950, we just need to realize that we are faced with problems that we don't have tools to address? We have discovered new possibilities and a new medium, but, we are trying to apply old tools and old thought patterns to this new stuff. Sounds like "accidental complexity" to me...
I'm on the record saying that we should deprecate the concepts of operating systems and of "programming languages". LLMs create code on the basis that functions are fundamental building blocks. Basically, anything produced by LLMs will be old-fashioned right out of the gate.
I didn't say "rewrite the same stack we have now, including all the worst decisions", I said "rewrite the stack", as in write a new software stack. Why do you almost always interpret my statements as being so much dumber than they actually are?... You're not the only one with insights, you know.
Anyway, instead of "rewrite the stack" maybe I should say "replace the stack".
> Maybe, like in 1950, we just need to realize that we are faced with problems that we don't have tools to address?
We should build the tools we need.
> I'm on the record saying that we should deprecate the concepts of operating systems and of "programming languages".
I disagree. Show us an alternative model that works in practice and then we can compare the paradigms.
Functions are indeed overrated, but an OS is important if only so multiple programs can run concurrently -- a necessary practicality -- and I still very much believe in text-based programming for most situations.
> Basically, anything produced by LLMs will be old-fashioned right out of the gate.
Not if you prompt them the right way.
We can tell LLMs to use whatever building blocks we want.
I will have LLMs implement the programming language I've been designing, which will save me many thousands of hours, and then LLMs will help me use that implemented language to build extremely simple, hopefully @jart-esque software that isn't dogshit.
> Functions are indeed overrated, but an OS is important if only so multiple programs can run concurrently -- a necessary practicality --
Why is running multiple programs a necessity?
I *think* that the only reason for this is a hold-over from the days of $1,000,000.00 CPUs. Now, that CPUs are $5.00, we can get true concurrency just by throwing more Arduinos at the problem (each running single-threaded).
Developers certainly want multiple programs to run on their development machines. End-users, though, don't need all of that oomph. What am I missing?
From my perspective, then, there is only one desirable aspect of O/Ss that remains - to provide a library of common functionality. We should want LEGO code blocks, but, function-based libraries don't give us that (they do _fool_ us into thinking that we get LEGOs, but, it ain't true). You can get LEGO code blocks very easily by using 0D ideas.
> and I still very much believe in text-based programming for most situations.
Text is OK, but it has been over-emphasized (hence, I tend to under-emphasize it (kind of a click-bait strategy)). SVG is on the right track. Text is but an element, a part of a bigger picture. You can have multiple text-based components in one project. "On the right track", though, does not mean that SVG has achieved nirvana, but is only pointing in a more reasonable direction. A futuristic programming CAD system would be a diagram editor that drops you into Emacs/VIM/VSCode when you want to edit a text-based 0D component.
"Most CPUs implement CALL and RETURN opcodes. These instructions were originally meant for sharing common bits of code"
Dear Paul, are you referring to GOSUB/RETURN statements in the BASIC language? These instructions permit to call a piece of code multiple times during the execution of the program. The called section is enclosed between a label and the RETURN instruction, but it has access to all the variables declared in the main section of the program. The code section called by GOSUB behaves like a subroutine without any input parameters, neither local variables. The GOSUB/RETURN couple is a very primitive version of CALL/RETURN paradigm.
GOSUB has subroutine semantics. I was referring to CPU opcodes for implementing subroutines. I know these opcodes as CALL and RET, although they were given different names in earlier CPUs. Claude says that EDSAC (1949) is often cited as the first practical implementation of subroutines.
Thanks for your answer! Sorry for my question: it was not clear. You argue (in many your posts) the CALL/RETURN statements where invented for subroutines, not for implementing functions. Are you referring to the simplest form of subroutine? I mean a subroutine with the following features:
_ no input/output parameters.
_ full access to global variables.
_ all local variables are static (they are allocated when the program is loaded, their values are kept between the subroutines calls).
This type of subroutine does not require a call stack.
One example of this simplest form of subroutine is the GOSUB/RETURN couple of statements in Basic.
Another example is a subroutine in Fortran 77 and earlier versions:
_ all local variables are static.
_ all parameters are passed to the called subroutine by address.
For this reasons, Fortran 77 and earlier versions have not a call stack.
That sounds about right.
As far as I know, subroutines were first invented for CPUs, then mimicked in languages like early BASIC and early Fortran.
Maybe these videos will help to further explain what I mean?
Evolution of Programming Functions https://www.youtube.com/watch?v=0sEvEr47OwI
Subroutine Calling https://www.youtube.com/watch?v=vWHtUBPg2-I
Nice post. I think this one does the clearest job of pointing out that what most programmers think of as the fundamental building blocks of software -- functions -- are in fact not fundamental at all.
> What is called “programming” today is not programming of bare CPUs, but, is only a function-based variant of programming that requires function-based engines and libraries. This is what we have. We’re not going to go back to square one and start all over. We have to build on what we have.
Speak for yourself :-D . In 3 years we'll be using LLMs to write entire operating systems with exactly the features we say we want, and no more. Those OSes will be written in whatever programming language we tell it to use, including momentarily-imaginary ones we prompt into existence.
The time has come to #RewriteTheStack .
Question: Do we need to rewrite the stack or simply to realize that the current stack cannot address the new set of problems? Maybe, like in 1950, we just need to realize that we are faced with problems that we don't have tools to address? We have discovered new possibilities and a new medium, but, we are trying to apply old tools and old thought patterns to this new stuff. Sounds like "accidental complexity" to me...
I'm on the record saying that we should deprecate the concepts of operating systems and of "programming languages". LLMs create code on the basis that functions are fundamental building blocks. Basically, anything produced by LLMs will be old-fashioned right out of the gate.
I didn't say "rewrite the same stack we have now, including all the worst decisions", I said "rewrite the stack", as in write a new software stack. Why do you almost always interpret my statements as being so much dumber than they actually are?... You're not the only one with insights, you know.
Anyway, instead of "rewrite the stack" maybe I should say "replace the stack".
> Maybe, like in 1950, we just need to realize that we are faced with problems that we don't have tools to address?
We should build the tools we need.
> I'm on the record saying that we should deprecate the concepts of operating systems and of "programming languages".
I disagree. Show us an alternative model that works in practice and then we can compare the paradigms.
Functions are indeed overrated, but an OS is important if only so multiple programs can run concurrently -- a necessary practicality -- and I still very much believe in text-based programming for most situations.
> Basically, anything produced by LLMs will be old-fashioned right out of the gate.
Not if you prompt them the right way.
We can tell LLMs to use whatever building blocks we want.
I will have LLMs implement the programming language I've been designing, which will save me many thousands of hours, and then LLMs will help me use that implemented language to build extremely simple, hopefully @jart-esque software that isn't dogshit.
> Functions are indeed overrated, but an OS is important if only so multiple programs can run concurrently -- a necessary practicality --
Why is running multiple programs a necessity?
I *think* that the only reason for this is a hold-over from the days of $1,000,000.00 CPUs. Now, that CPUs are $5.00, we can get true concurrency just by throwing more Arduinos at the problem (each running single-threaded).
Developers certainly want multiple programs to run on their development machines. End-users, though, don't need all of that oomph. What am I missing?
From my perspective, then, there is only one desirable aspect of O/Ss that remains - to provide a library of common functionality. We should want LEGO code blocks, but, function-based libraries don't give us that (they do _fool_ us into thinking that we get LEGOs, but, it ain't true). You can get LEGO code blocks very easily by using 0D ideas.
> and I still very much believe in text-based programming for most situations.
Text is OK, but it has been over-emphasized (hence, I tend to under-emphasize it (kind of a click-bait strategy)). SVG is on the right track. Text is but an element, a part of a bigger picture. You can have multiple text-based components in one project. "On the right track", though, does not mean that SVG has achieved nirvana, but is only pointing in a more reasonable direction. A futuristic programming CAD system would be a diagram editor that drops you into Emacs/VIM/VSCode when you want to edit a text-based 0D component.