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

Computer Science from the Bottom Up

bottomupcs.com

Post reply on HN
Print view View original

91–100 of 104 posts

Re: Computer Science from the Bottom Up

#91

Post by pugio »

mattwillmart wrote: post #87
akersten wrote: post #52

Earlier quoted context omitted.

Yeah, the first page of this book being "Everything is a File in Unix" is already so high-level and far above what I would call the "bottom-up" of computer science that this book should be renamed "Unix from the bottom-up." The "bottom" of computer science would be mathematically explaining what it means to compute, and building up to the abstraction of a Turing machine, and eventually getting to a concrete implement…

Do you know a book like this? Sounds interesting to me as someone who is very interested in computing, but never went to university. Specifically "mathematically explaining what it means to compute, and building up to the abstraction of a Turing machine" Thanks

Take a look at: Understanding Computation: From Simple Machines to Impossible Programs by Tom Stuart.

It's pretty much "computation theory for the everyday programmer". It uses Ruby to implement things like Turing Machines and the lambda calculus. Extremely accessible, and a lot of fun.

Re: Computer Science from the Bottom Up

#92

Post by bollu »

R0b0t1 wrote: post #73
khaledh wrote: post #59

Earlier quoted context omitted.

From "Operating Systems: Three Easy Pieces" chapter on "Process API" (section 5.4 "Why? Motivating The API") [1]: ... the separation of fork() and exec() is essential in building a UNIX shell, because it lets the shell run code after the call to fork() but before the call to exec(); this code can alter the environment of the about-to-be-run program, and thus enables a variety of interesting features to be readily bui…

This is not enough of an explanation as these things are still possible with CreateProcess. I do remember reading the real explanation -- it was easier to implement fork. That's it.

I'd like a reference for this explanation :)

Re: Computer Science from the Bottom Up

#93

Post by saurik »

R0b0t1 wrote: post #73
khaledh wrote: post #59

Earlier quoted context omitted.

From "Operating Systems: Three Easy Pieces" chapter on "Process API" (section 5.4 "Why? Motivating The API") [1]: ... the separation of fork() and exec() is essential in building a UNIX shell, because it lets the shell run code after the call to fork() but before the call to exec(); this code can alter the environment of the about-to-be-run program, and thus enables a variety of interesting features to be readily bui…

This is not enough of an explanation as these things are still possible with CreateProcess. I do remember reading the real explanation -- it was easier to implement fork. That's it.

These things are possible with APIs like CreateProcess or posix_spawn, but involve the API ending up with a million little customizable parameters in the attempt to simulate all of the behaviors that can trivially be implemented if you just support "let me run some code in the target process before I replace its memory"... which is like, exactly why "easier to implement" sort of means: something is often easier to implement if it is a single universal and general primitive that forms an elegant solution to a wide set of problems rather than being a myriad collection of hacks for various use cases. As an API--particularly on systems with copy-on-write pages--fork is amazing.

Re: Computer Science from the Bottom Up

#94

Post by [deleted] »

saurik wrote: post #93
R0b0t1 wrote: post #73

Earlier quoted context omitted.

This is not enough of an explanation as these things are still possible with CreateProcess. I do remember reading the real explanation -- it was easier to implement fork. That's it.

These things are possible with APIs like CreateProcess or posix_spawn, but involve the API ending up with a million little customizable parameters in the attempt to simulate all of the behaviors that can trivially be implemented if you just support "let me run some code in the target process before I replace its memory"... which is like, exactly why "easier to implement" sort of means: something is often easier to im…

[deleted]

Re: Computer Science from the Bottom Up

#95

Post by NobodyNada »

RcouF1uZ4gsC wrote: post #86
mhh__ wrote: post #82

> All modern architectures would be considered RISC architectures no no no no no no no no It is sort of like RISC on the inside (uOps), but x86 is __not__ RISC on the outside, which means it has to have a thumping great decoder and a bunch of microcode using power all the time. Locally even if the microarchitecture could be considered a RISC, the architecture of an X86 computer cannot be considered RISC both on accou…

I think modern architectures are neither RISC nor CISC. Successful modern architectures have adopted features of both. Even the most RISC architecture these days likely has AES instructions. Even the most CISC architecture is using RISC like micro ops.

> Even the most RISC architecture these days likely has AES instructions

AFAIK these sorts of instructions are typically things that would be trivial to implement in hardware but extremely cumbersome to implement in software, like shuffling a bunch of bits around (ARM's "JavaScript instruction" is another famous example). These sorts of things would only require a single micro-operation (or a very small number of uops).

My understanding is that the big distinction between CISC/RISC comes from things like addressing modes, by which a CISC processor lets you cram many hardware operations into a single software instruction. For instance, on x86 you can write an instruction like 'ADD rax, rbx, [rcx + 0x1234 + 8*rdx]' that performs several additions, a bit shift, and a memory access. Whereas on ARM, you would have to split those multiple hardware operations into multiple instructions.

> Even the most CISC architecture is using RISC like micro ops

Yes, but as the parent comment points out, that requires a complicated decoder with limited throughput. Using a RISC architecture throughout therefore moves some (but not all) of that instruction-decoding work into the compiler.

(I'm not at all knowledgeable in the field of processor design, so I would be happy to be proven wrong.)

Re: Computer Science from the Bottom Up

#96

Post by pjc50 »

R0b0t1 wrote: post #73
khaledh wrote: post #59

Earlier quoted context omitted.

From "Operating Systems: Three Easy Pieces" chapter on "Process API" (section 5.4 "Why? Motivating The API") [1]: ... the separation of fork() and exec() is essential in building a UNIX shell, because it lets the shell run code after the call to fork() but before the call to exec(); this code can alter the environment of the about-to-be-run program, and thus enables a variety of interesting features to be readily bui…

This is not enough of an explanation as these things are still possible with CreateProcess. I do remember reading the real explanation -- it was easier to implement fork. That's it.

Running code in the target process space before the target executable is loaded is not possible with CreateProcess. Configuration of the target process has to be done by the operating system, via an ever-growing list of attributes you can pack into STARTUPINFOEX. https://docs.microsoft.com/en-us/windows/win32/api/processth...

UNIX fork/exec is also significantly faster than CreateProcess, but I'm not sure how much of that is necessary rather than contingent, or results of an ever growing list of "security" programs insisting on a veto. https://stackoverflow.com/questions/47845/why-is-creating-a-...

Fork+IPC architecture - effectively multithreading but where the processes don't automatically share memory and can crash separately - also requires fork(). However this has very much fallen out of fashion.

() I suppose you can emulate fork by calling CreateProcess with an empty executable and CREATE_SUSPENDED, then use various debug APIs to overwrite its memory map with your own, but this is very messy.

Re: Computer Science from the Bottom Up

#97

Post by CRConrad »

dataflow wrote: post #77
megous wrote: post #76

Earlier quoted context omitted.

Users don't fork processes, it's a low-level system thing.

Why repeat the same thing as the sibling comment posted an hour ago...?

Usually because you've had the browser open for a while and are seeing the state after the parent, but before the sibling comment was posted. At least that's usually why it happens for me; refreshing to see if someone else already has said what you want to say is rarely uppermost in my mind when a reply comes to mind.

Another possibility (pretty clearly not the case here) is when there are lots of replies: either you just miss it among the others, or ypu just can't be bothered to scroll down half a mile.

Re: Computer Science from the Bottom Up

#98

Post by nicklecompte »

brundolf wrote: post #2

This seems highly focused on systems; I wouldn't call it representative of "Computer Science" as a whole. Only maybe 2-3 of the classes in my computer science degree were focused on this kind of stuff. Still seems like a good resource, just perhaps mislabeled.

The introduction is a much better description:

> In a nutshell, what you are reading is intended to be a shop class for computer science. Young computer science students are taught to "drive" the computer; but where do you go to learn what is under the hood?

And “Shop Class For Computer Scientists” or “Systems Engineering From The Bottom Up” would have been better titles. It’s simply misleading to suggest a course comprehensively covers “computer science” without covering algorithms or complexity, among many other things.

Re: Computer Science from the Bottom Up

#99

Post by nicklecompte »

zerkten wrote: post #13
brundolf wrote: post #2

This seems highly focused on systems; I wouldn't call it representative of "Computer Science" as a whole. Only maybe 2-3 of the classes in my computer science degree were focused on this kind of stuff. Still seems like a good resource, just perhaps mislabeled.

> This seems highly focused on systems; I wouldn't call it representative of "Computer Science" as a whole. I'd agree with this, but it fits with how a certain set of schools teaches their core. They will teach a set of related classes around the topics here: computer architecture, operating systems, and networking, because this is often central to their research interests. Others will scatter this information across…

I was a math major (in the US) so I don’t recall exactly, but I think my university offered both BA and BS degrees in computer science, where the BA focused more algorithms and complexity (overlap with math majors) while the BS focused on operating systems and hardware (overlap with electrical engineering majors). For postgraduates there is an academic MS in computer science versus a more practical MEng in software/computer engineering.

I think this is a good system - and also indicates that we are speaking somewhat past each other on what a “computer science” education looks like.

Re: Computer Science from the Bottom Up

#100

Post by randcraw »

froh wrote: post #69

is there some real "bottom up" curriculum? in retrospect I feel lucky to have grown with the tech: * TI58C programmable calculator, a handfull of registers, load store, conditional jump, that's it, essentially a very simple assembly-like language. * then CBM basic, two letter variable names, only globals, line numbers and goto/gosub * then (turbo) pascal with scopes, still single process unicore everything * then a l…

Computer Engineering departments and degrees emphasize the stuff you mention more than CS does.

CE largely extends its focus on software up to networking and O/Ses and down to compilers and instruction sets. And on the hardware side, from motherboards, interconnects, and peripherals down to CPUs, with side trips into non-PC architectures like SoCs (e.g. Raspberry Pi) and GPUs.

The CE emphasis seems to be on the engineering tradeoffs of computer hardware design and implementation (at the symbolic level) and how it interacts with software. However, CE doesn't seem to take the next step down into VLSI or power or heat management or chip failure or transistor microelectronics, largely which remain the purview of EEs.

Not all CE programs are strict about these emphases, however. Some adopt the name CE without moving appreciably away from mainstream CS. I suspect the name 'CE' better serves some professors' priorities and helps them sell their work as being rooted in engineering rather than in the abstractions and symbols rooted in math, from whence CS came.

Post reply on HN