This has tons of sugar; if you're just interested in how this stuff is possible in C it would probably be more instructive to look at the GNU library libffcall[0] which implements trampolines. The code is simpler and there's less syntactic sugar obscuring what's going on. Of course, the linked articles on the Cello home page are instructive too.
I've yet to actually use Cello myself since I feel like if you hack C up that much, you might as well just use something like C++, C#, Rust or what have you and gain even more benefits, like a mature ecosystem that's highly compatible with the features you're using while I worry Cello, when relying on normal C libraries, might require you to slip back into some C-isms that Cello desires to avoid due to your dependencies not caring.
I've yet to actually use Cello myself since I feel like if you hack C up that much, you might as well just use something like C++, C#, Rust ....
Since the early 90's I never understood why some programmers insist in using what is basically a portable macro assembler for higher level programming.
It was already primitive when compared with the likes of Modula-2 and Turbo/Apple Pascal, not to mention all the other alternatives even higher level.
In general, because those languages essentially declared things were 'bad' that aren't bad at all. Sometimes you have to mung data. Pull it in off a serial bus, strip out the header, rearrange it for the next thing you are sending it to, and so on. Other times you really do need/want some kind of dynamic dispatch or duck typing. You can do that with void* and function pointers. Ugly, yes, and error prone to boot, but possible. These days hardware is a lot faster. Back then I was writing my own graphics implementations because Windows GDI was way too slow for what I was trying to do. Just for a pretty ordinary app. Today, I am still concerned with how my data lies on the CPU cache. I need to access cards with C api's. It is nice to think about things like rust, but in my current company we have 2 decades worth of C&C++ code. It works with everything; we know that if a new card comes out it will come with a C API, we know that we can hire C programmers. The debuggers are astonishingly good (seriously; compare Visual Studio's debugger to thrashing around with some open source debugger for some other language. It's a production language, for professionals, to get shit done. It's not going anywhere for a long, long time.
Not putting down the other languages - I use Python whenever I can, as it is such a joy to use. Anything other than C/C++ for most of my production code? Not in the foreseeable future.
If you feel the urge to quibble about that last sentence, recall how much existing code I (and by extension, the world) already have. Never, ever, can we afford to throw that away. Shall we write some horror show of Haskell, Erlang, Javascript, and Clojure interfacing into 'legacy' code that in fact would need to be updated all the time? No thanks. For all the hand wringing about memory management, between smart pointers (rolled my own before there were library versions) and RAII I can't remember the last time I spent a serious amount of time chasing down a resource leak. Maybe early 90's? I dunno, but it seems that I spend more time debugging Python code where I am passing in a variable of the wrong type and Python just silently spits out the wrong thing in response.
Would I like a 'better' language than C? Absolutely! Do I see one in my future? Not really. Because it is actually awesome at doing the kinds of things that need to be done.
It wasn't just the lack of a cast. (IIRC, you could work around that with variant records if you really had to, though it was really clumsy.)
Another, unfixable problem was that the size of an array was part of the type of the array. This meant that you couldn't ever access past the end of an array, which was good. It also meant that you could never have a variable-sized array - you couldn't even talk about the type of such a thing.
This meant that Pascal was completely unusable for writing, say, a memory manager (what type would you give to the return from an allocation)? But that's a low level problem. It also meant that Pascal couldn't be used for a numeric simulation where the size of your grid was a user-supplied runtime value.
Note that I am only talking about the original (Wirth/UCSD) Pascal. I believe that Turbo Pascal fixed the variable-sized array problem.
When implementing an OS avoiding Assembly is impossible. Even if intrisics are used instead, they are just another way of using Assembly like instructions.
There are lots of informations in this book, "Revolution in The Valley: The Insanely Great Story of How the Mac Was Made".
They used more than some assembly. Andy Hertzfeld:
"But most of the Lisa code was written in the Pascal programming language. Since the Macintosh had much tighter memory constraints, we needed to write most of our system-oriented code in the most efficient way possible, using the native language of the processor, 68000 assembly language. Even so, we could still use Lisa code by hand translating the Pascal into assembly language.
"We directly incorporated Quickdraw, Bill Atkinson's amazing bit-mapped graphics package, since it was already written mostly in assembly language. We also used the Lisa window and menu managers, which we recoded in assembly language from Bill's original Pascal, reducing the code size by a factor of two or so. Bill's lovely Pascal code was a model of clarity, so that was relatively easy to accomplish."
Also, about half the LOC in MacPaint were assembly.
You're probably remembering something from Brian Kernighan's 1981 essay, "Why Pascal Is Not My Favorite Programming Language". Lack of unsafe typecasts, as well as (I think) all of Kernighan's other main points in that essay were cured in Pascal implementations by end of the 80's. But by that time C had captured all the mindshare.
Large parts of my undergraduate curriculum in the early 90s (at a mid-size well-funded public school in the united states) used pascal, and the unix and vms compilers we used most certainly suffered from the 'different array sizes are different types' issue.
Comments
Previous discussion: https://news.ycombinator.com/item?id=6047576
This has tons of sugar; if you're just interested in how this stuff is possible in C it would probably be more instructive to look at the GNU library libffcall[0] which implements trampolines. The code is simpler and there's less syntactic sugar obscuring what's going on. Of course, the linked articles on the Cello home page are instructive too.
I've yet to actually use Cello myself since I feel like if you hack C up that much, you might as well just use something like C++, C#, Rust or what have you and gain even more benefits, like a mature ecosystem that's highly compatible with the features you're using while I worry Cello, when relying on normal C libraries, might require you to slip back into some C-isms that Cello desires to avoid due to your dependencies not caring.
[0]: https://www.gnu.org/software/libffcall/
Since the early 90's I never understood why some programmers insist in using what is basically a portable macro assembler for higher level programming.
It was already primitive when compared with the likes of Modula-2 and Turbo/Apple Pascal, not to mention all the other alternatives even higher level.
In general, because those languages essentially declared things were 'bad' that aren't bad at all. Sometimes you have to mung data. Pull it in off a serial bus, strip out the header, rearrange it for the next thing you are sending it to, and so on. Other times you really do need/want some kind of dynamic dispatch or duck typing. You can do that with void* and function pointers. Ugly, yes, and error prone to boot, but possible. These days hardware is a lot faster. Back then I was writing my own graphics implementations because Windows GDI was way too slow for what I was trying to do. Just for a pretty ordinary app. Today, I am still concerned with how my data lies on the CPU cache. I need to access cards with C api's. It is nice to think about things like rust, but in my current company we have 2 decades worth of C&C++ code. It works with everything; we know that if a new card comes out it will come with a C API, we know that we can hire C programmers. The debuggers are astonishingly good (seriously; compare Visual Studio's debugger to thrashing around with some open source debugger for some other language. It's a production language, for professionals, to get shit done. It's not going anywhere for a long, long time.
Not putting down the other languages - I use Python whenever I can, as it is such a joy to use. Anything other than C/C++ for most of my production code? Not in the foreseeable future.
If you feel the urge to quibble about that last sentence, recall how much existing code I (and by extension, the world) already have. Never, ever, can we afford to throw that away. Shall we write some horror show of Haskell, Erlang, Javascript, and Clojure interfacing into 'legacy' code that in fact would need to be updated all the time? No thanks. For all the hand wringing about memory management, between smart pointers (rolled my own before there were library versions) and RAII I can't remember the last time I spent a serious amount of time chasing down a resource leak. Maybe early 90's? I dunno, but it seems that I spend more time debugging Python code where I am passing in a variable of the wrong type and Python just silently spits out the wrong thing in response.
Would I like a 'better' language than C? Absolutely! Do I see one in my future? Not really. Because it is actually awesome at doing the kinds of things that need to be done.
Wasn't there some issue with Pascal type system being too restricting sometimes (the unfortunate lack of cast) ?
It wasn't just the lack of a cast. (IIRC, you could work around that with variant records if you really had to, though it was really clumsy.)
Another, unfixable problem was that the size of an array was part of the type of the array. This meant that you couldn't ever access past the end of an array, which was good. It also meant that you could never have a variable-sized array - you couldn't even talk about the type of such a thing.
This meant that Pascal was completely unusable for writing, say, a memory manager (what type would you give to the return from an allocation)? But that's a low level problem. It also meant that Pascal couldn't be used for a numeric simulation where the size of your grid was a user-supplied runtime value.
Note that I am only talking about the original (Wirth/UCSD) Pascal. I believe that Turbo Pascal fixed the variable-sized array problem.
Those problems were not part of the Pascal dialects.
The largely ignored Extended Pascal ISO standard also had those issues fixed.
The first Mac OS versions were written in Apple Pascal.
I knew about Apple programs being in Pascal, but the whole OS ? did they resort to inline asm ?
Yes, they did use Assembly.
When implementing an OS avoiding Assembly is impossible. Even if intrisics are used instead, they are just another way of using Assembly like instructions.
There are lots of informations in this book, "Revolution in The Valley: The Insanely Great Story of How the Mac Was Made".
They used more than some assembly. Andy Hertzfeld:
"But most of the Lisa code was written in the Pascal programming language. Since the Macintosh had much tighter memory constraints, we needed to write most of our system-oriented code in the most efficient way possible, using the native language of the processor, 68000 assembly language. Even so, we could still use Lisa code by hand translating the Pascal into assembly language.
"We directly incorporated Quickdraw, Bill Atkinson's amazing bit-mapped graphics package, since it was already written mostly in assembly language. We also used the Lisa window and menu managers, which we recoded in assembly language from Bill's original Pascal, reducing the code size by a factor of two or so. Bill's lovely Pascal code was a model of clarity, so that was relatively easy to accomplish."
Also, about half the LOC in MacPaint were assembly.
Basic, Forth, C and Pascal were the Ruby and Python of the 80's home computers, both in compiler code quality and memory usage.
Of course anything related to graphics programming would be written in pure Assembly code, so excuse me if I misused "Some".
Yes indeed, I forgot about that. I wonder if there ever was a purely 'compiled' OS from some declarative form.
You're probably remembering something from Brian Kernighan's 1981 essay, "Why Pascal Is Not My Favorite Programming Language". Lack of unsafe typecasts, as well as (I think) all of Kernighan's other main points in that essay were cured in Pascal implementations by end of the 80's. But by that time C had captured all the mindshare.
No, that was a problem only with the original Pascal as designed by Niklaus Wirth for teaching purposes.
None of the Pascal dialects that extended it with features for professional programming suffered from it.
Large parts of my undergraduate curriculum in the early 90s (at a mid-size well-funded public school in the united states) used pascal, and the unix and vms compilers we used most certainly suffered from the 'different array sizes are different types' issue.