ckirsch / book Goto Github PK

Hi, here, I have a question when reading the EBNF part of the book.

A pushdown automaton is a finite state machine with a stack

Did you assume that the size of the stack is infinite?

Let's say you have a finite state machine with a stack size of N(an integer).

Any context-free grammar can be implemented by a pushdown automaton (PDA)

Is this argument still true?

Thanks for writing this! Some small stuff I noticed while reading what you have so far follows, feel free to take action (or not) as you wish.

The images are off-yellow on off-white drawings. Can you switch them to be thicker, and in higher contrast? For example, blue-on-white. Print (not cursive) would also be nice.

While a fan, IMO your book recommendation of TaOCP is insane :)

I didn't get a clear idea of what the program runs did. Could you explain the command line flags as you use them better?

As a reader coming in with some existing knowledge, I would love more mentions of "we will talk about this later in chapter ". For example, assembly code gets mentioned later in "Machine".

"but still." as a sentence ending is maybe is too conversational to come off well in writing.

The mention of files as pointers to memory is a pretty big simplification. I would keep it that way, but mention that it is? I feel like otherwise readers would end up disappointed later when they learned more.

The mention of latency in the I/O section was very unclear to me.

2^20^B should be 2^20 bytes. (and ^particles, ^states etc later). I think this is a formatting bug (attempt at superscript rather than made-up notation) but it's not rendering on github.

The tables near the bytes count show a leading [ on the left column.

You say: "State-of-the-art video compression can bring down size and bit rate by up to two orders of magnitude with negligible loss in quality." You then mention "could take us from 2.6TB to around 9GB". This is two si-prefixes, or about 6 orders of magnitude as the term is normally used.

The I/O section might mention networking or hard drives, even briefly.

"Adding 1s, if the MSB, that is, the sign bit is 1, and otherwise adding 0s, is called arithmetic right shift [...]" -> Adding copies of the MSB, sign bit, or leftmost bit (all the same thing) is called arithmetic right shift [...]".

When talking about static vs dynamic allocation, remind people what global and local variables are with a short code example.

My eyes generally glazed over a bit when running over instructions. There are a lot of cryptic abbreviations and it's all fairly boring. I would have appreciated a clear division into "now we are teaching you the list of instructions" and "now we are talking about general stuff; don't try to memorize these incompletely-explained instrucitons". Adding human-readable names or fully explaining the names would help a little. Also maybe just shorten the section?

Hate to say it but markdown might not be the best tool for this section, either.

Reduce the two mentions of nop to one.

"However, real computers often show behavior that appears to be non-deterministic such as a software bug that only shows up once in a while. Nevertheless, non-determinism is not the root cause of that, at least as long as the machine is not broken." -- this is basically not true out of context. Outside of RISC-U, there are many other kinds of non-deteminism--timing, mutlithreading, past state on the computer like inode order, etc.

Based on what you have so far, I think cutting out the bit about regular expressions seems reasonable. I'm not sure if EBNF is used, but maybe that too? EBNF at least makes sense to people.

In the following paragraph:

The procedures encode_i_format and decode_i_format in the source code of selfie encode and decode instructions in I-Format, respectively. There are similar procedures for other formats introduced below as well. Note that the source code of selfie mostly uses the keyword uint64_t instead of the keyword int. In C* both keywords mean the same thing: unsigned integer 64-bit type! However, the keyword int actually means something different in standard C which may be confusing to readers who know C. So, here int is just like uint64_t.

The part about usage of uint64_t instead of int seems out of place - it seems weird that this is mentioned in the section on RISC-U. A better place to mention this might be the section on C* that already mentions uint64_t and bootstrapping int to uint64_t.

I've noticed that code blocks get cut off when rendered in the PDF.

I've not gotten through the whole book yet, and it's not been much of an issue, there were just a couple times, like the output of ./selfie, where it got cut off and you couldn't completely see something referenced by the book text.

If you are interested I could probably add a Typst template that could be used to typeset the markdown as a PDF with wrapping codeblocks.