ThinkingLowWritingHighLevel_RandallHyde

Question 1

What should we know before reading this book?

Answer 1

Competent in one procedural language (C, C++, BASIC, Pascal, Assembly, Ada, FORTRAN, Modula-2)

Able to design a software solution for a small problem description

Basic grasp of machine organization and data representation

Hexadecimal and binary numbering systems

How computers represent high level data types like signed integers, characters, strings in memory.

Why?

We’ll receive the greatest benefit from the material if we have these skills

Question 2

What topics does this volume cover?

Answer 2

Why it’s important to consider low-level execution of your high level programs

How compilers generate machine code from high-level language (HLL) statements

How compilers represent various data types using low-level, primitive, data types

How to write HLL code to help the compiler produce better machine code

How to take advantage of a compiler’s optimization facilities

How to “think” in assembly language (low-level terms) while writing HLL code

Question 3

What language was high-performance software written during the early days of the personal computer revolution?

Answer 3

Assembly language

Then?

Optimizing compilers for HLL were improved and author’s began to claim the machine instructions generated by compilers performed at 90% of hand-optimized assembly speed

Question 4

What problem happened with the new generation of programmers using high-level languages?

Answer 4

They did not have benefit of understanding assembly!

Therefore, they were unable to choose statements and data structures that HLLs could efficienctly translate into machine code

Original programmers did understand assembly and used HLLs with low-level ramifications in mind

Question 5

What is the purpose of this book?

Answer 5

Teach you what you need to know to write great code without having to become an expert at assembly language

Question 6

What is the major problem with using optimizing compilers?

Answer 6

They allow programmers to get lazy!

No optimizing compiler can make up for poorly written HLL source code.

Question 7

What is a misconception among HLL programmers?

Answer 7

optimization algorithms in modern compilers will produce efficient code regardless of what they feed into their compilers.

No!

It’s easy to feed a compiler poorly written code that stymies the optimization algorithms of a compiler!

Question 8

What is the problem with high-level language programmers?

Answer 8

They never actually looked at the machine code the compiler produces from their high-level language source code!

They blindly assume the compiler is doing a good job because they’ve been told:

“compilers produce code that is almost as good as what an expert assembly language programmer can produce.”

Question 9

What won’t a compiler do?

Answer 9

Change your algorithms in order to improve the performance of your software

Ex. Use a linear search rather than binary search

cannot expect compiler to substitute better algorithm for you

It can improve speed of your linear search but improvement may be nothing compared to using a better algorithm

Question 10

What type of code is comparable to code produced by expert assembly language programmers?

Answer 10

Manually optimized code:

High Level: Select better algorithms (independent of compiler and language)

Lower Level: Manually optmize code based on HLL (apply across different compilers, same language)

Lower Level: Compiler specific optmizations (structure code to take advantage of tricks in specific versions of compilers)

Lowest Level: Consider machine code compiler emits and adjust HLL statemnts to force desired sequence of machine instructions

The issue?

Most people do not go to these extremes to write their HLL code

Question 11

What are the manual levels of optimization?

Answer 11

Most abstract: Select better algorithms (independent of compiler and language)

Less Abstract : Manually optmize code based on HLL (apply across different compilers, same language)

Less Abstract: Compiler specific optmizations (structure code to take advantage of tricks in specific versions of compilers)

Least Abstract: Consider machine code compiler emits and adjust HLL statemnts to force desired sequence of machine instructions

Why?

Programmers employing this process will produce the best possible machine code!

Question 12

Under what conditions can an optimizing compiler produce code that is almost as good as hand-optimized assembly language?

Answer 12

When the HLL code is written in an appropriate fashion to achieve these performance levels

To write HLL code like this requires understanding how computers operate and execute software

Question 13

How do I write high-level code so that the compiler can translate it most efficiently?

Answer 13

Answer:

Think in assembly, write in high-level language

Question 14

What does the fact that we can achieve the same result with two high-level language code sequences not imply?

Answer 14

That the compiler generates the same sequence of machine instructions for each sequence

Ex. If-else vs. switch statement

in HLL achieve same result, machine instructions are different!

Which is faster?

Unless we understand how compiler translates statements like these into machine code and understand different efficiencies between machine instructions, cannot choose one over the other!

Question 15

When will the compiler rarely generate the best possible machine code?

Answer 15

If a programmer does not consider the low-level ramifications of the HLL code (how it’s translated into machine code and the efficiencies of various machine instructions)

Question 16

What must we know to choose between two equivalent HLL statements?

Answer 16

how compiler translates statements into machine code and different efficiencies between machine instructions, to choose one over the other!

Question 17

What is more important than learning to write assembly language?

Answer 17

Understanding how high-level languages translate statements into machine code so you can choose appropriate HLL statements

Question 18

What advice did vetran programmers give to new programmers who didn’t learn assembly?

Answer 18

“If you want to learn how to write good HLL code, you need to learn assembly language. “

Why?

By learning assembly language, a programmer would be able to consider the low-level implications of their code and make informed decisions concerning the best way to write applications in higher level languages.

Question 19

Why won’t thinking low-level while developing in high-level lengthen overall project schedules?

Answer 19

initial coding will be slowed down

resulting HLL will possess efficiency it wouldn’t otherwise have

Once code is written, you won’t have to think about it in low-level terms during maintencance and enhancement phases of software development

Result:

thinking in low-level terms during initial software development stage will retain advantages of both low-level (efficiency) and high-level coding (ease of maintenance)

Question 20

What is directly related to the number of machine instructions and type of machine instructions a compiler emits?

Answer 20

The amount of space in memory an application uses

The amount of time an application spends in execution

Question 21

Does thinking low-level while writing high-level negate the benefits of HLL programming (faster development, better readability, easier maintenance)?

Answer 21

No.

It’s slower to start but resulting code will have efficiencies it wouldn’t otherwise have

After code is written, maintenance and enhancement phases won’t need to consider low-level details anymore

Question 22

What does great code mean?

Answer 22

Different programmers have different definitions.

However, certain attributes everyone agrees:

• Great code uses the CPU efficiently (code is fast)
• Great code uses memory efficiently (code is small)
• Great code uses system resources efficiently
• Great code is easy to read and maintain
• Great code follows a consitent set of style guidelines
• Great code uses an explicit design that follows established software engineering conventions
• Great code is easy to enhance
• Great code is well tested and robust ( this is, it works)
• Great code is well documented

Additional points other engineers may say:

• Great code is portable
• Great code is written in certain languages
• Great code is written as simply as possible
• Great code is written quickly
• Great code is created on time and under budget

Question 23

What aspects of great code does this volume concentrate?

Answer 23

Some of the efficiency aspects of writing great code

Why?

Although efficient code isn’t always the primary goal most people generally agree that inefficient codes is not great code.

Is ineffient code sometimes great?

Yes, however grossly inefficient (noticeably inneficient) never qualifies as great code.

Question 24

What languages and compilers does this book use in various examples?

Answer 24