Compiler Design Spring 2018 5.0 Software design Thomas R. Gross - - PowerPoint PPT Presentation

compiler design
SMART_READER_LITE
LIVE PREVIEW

Compiler Design Spring 2018 5.0 Software design Thomas R. Gross - - PowerPoint PPT Presentation

Compiler Design Spring 2018 5.0 Software design Thomas R. Gross Computer Science Department ETH Zurich, Switzerland 1 Outline Code quality What to do about it Practical example 2 Code quality What is quality? All exams


slide-1
SLIDE 1

Compiler Design

Spring 2018

5.0 Software design

1

Thomas R. Gross Computer Science Department ETH Zurich, Switzerland

slide-2
SLIDE 2

Outline

§ Code quality § What to do about it § Practical example

2

slide-3
SLIDE 3

Code quality

§ What is “quality”? § All exams have high quality.

§ Student: Exam asks questions that check material on the handout. § Lecturer: Exam shows that students can apply material to new problem(s). § Dean (head of studies): The results follow normal distribution. § Provost: Successful students are great ambassadors for the college. § Teaching assistant: Exam was multiple choice (and therefore could be graded while watching soccer).

3

slide-4
SLIDE 4

Quality

§ Need to identify dimensions

§ Need to define “low” and “high” marks

§ Without clarification vague § Near term goal: code reviews

§ By students § Of students’ code: Solution submitted for Homework 3

4

slide-5
SLIDE 5

Quality

§ Near term goal: code reviews § Why?

§ Code reviews are common § Code reviews highly effective to improve software systems

§ Other techniques exist as well

5

slide-6
SLIDE 6

Code quality

§ First focus: software system artifact

§ Source code § Documents

§ External characteristics of software system

§ Visible/noticeable by “user”

§ Internal characteristics of software system

§ Primarily of interest to developer

§ Other aspects: process, environment, …

6

slide-7
SLIDE 7

External characteristics

§ Boundary to internal characteristics not always strict § Dimensions are not always mutually exclusive § Correctness: freedom from faults

§ Faults in specification § Faults in design § Faults in implementation § Faults in execution

§ Robustness: ability to handle invalid input

§ Useful error messages § May have to include handling of hardware faults

7

slide-8
SLIDE 8

External characteristics (cont’d)

§ Usability

§ Serves its purpose

§ Adaptability: system can be used w/o modifications in other scenarios

§ Interoperates with other systems as designed/specified

§ Integrity: prohibit unauthorized/improper access

8

slide-9
SLIDE 9

External characteristics (cont’d)

§ Traceability: completeness of access traces and/or logs § Accuracy: results acceptable with regard to quantitative input

§ Could be considered a correctness issue

§ Reliability: system performs under stated conditions

9

slide-10
SLIDE 10

Internal characteristics

§ Flexibility: system can be modified (with little or no effort) to be used for unintended environments § Reusability: system can be used in another operating environment § Readability: source code can be understood

10

slide-11
SLIDE 11

Readability

§ Numerous factors influence readability

§ Consistent style (formatting)

§ Use of white space § Use of indentation § Tools can help

§ Rules for names, naming conventions § Rules for comments § Use of language features

§ Choice of programming language(s)

11

slide-12
SLIDE 12

Readability

§ Numerous factors influence readability

§ Use of assertions § Coding conventions

§ Size of functions § Use of exceptions

§ File (project) organization/directory structure

12

slide-13
SLIDE 13

Readability à Understandability

§ System structure

§ Reflects high-level design § Modularity

§ Coherence and cohesion

§ Number of interaction points with other modules § Number of parameters

§ Control flow

§ Use of exceptions § Control/data plane

13

slide-14
SLIDE 14

Understandability

§ Level required to comprehend system

§ Classes (structs, records) § Class hierarchies

§ Depth

§ Frameworks § Patterns

14

slide-15
SLIDE 15

Internal characteristics (cont’d)

§ Maintainability: source code can be modified to address changing requirements

§ Improve performance § Improve usability § Address correctness and security problems § Correct defects as well as react to environment changes

§ Testability: Can you unit test the system?

§ How easy it is to verify that the system meets requirements

16

slide-16
SLIDE 16

public void HandleStuff(CORP_DATA inputRec, int crntQtr, EMP_DATA empRec, double estimRevenue, double ytdRevenue, int screenX, int screenY, COLOR_TYPE newColor, COLOR_TYPE prevColor, StatusType status, int expenseType) { int i; for (i = 0; i < 100; i++) { inputRec.revenue[i] = 0; inputRec.expense[i] = MASTER.corpExpense [crntQtr][i]; } MASTER.UpdateCorporateDatabase( empRec ); estimRevenue += ytdRevenue * 4.0 / (double) crntQtr; newColor.color = prevColor.color; status.result = Result.SUCCESS; if ( expenseType == 1) { for (i = 0; i < 12; i++) MASTER.profit[i] = inputRec.revenue[i] - MASTER.expense.type1[i]; } else if ( expenseType == 2) { MASTER.profit[i] = inputRec.revenue[i] - MASTER.expense.type2[i]; } else if ( expenseType == 3) MASTER.profit[i] = inputRec.revenue[i] - MASTER.expense.type3[i]; } 18

Adapted from S. McConnell, Code Complete (2nd Edition)

slide-17
SLIDE 17

What’s wrong with this routine?

Look at this example of Java code and find with your neighbor problems with it. You should be able to find at least 10 different problems. Take 5 minutes.

20

slide-18
SLIDE 18

Comments

§ Internal/external characteristics may overlap

§ Correlated, not independent

§ Often no fixed rule on “good design”

§ Example: size of functions/methods § Example: number of method arguments

§ Texts to consider

§ Steve McConnell: Code Complete: A Practical Handbook of Software Construction, Microsoft Press, 2004. § George A. Miller: The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information, Psychological Review, 1956, vol. 63, pp. 81-97

26

slide-19
SLIDE 19

Software quality

§ Goal: design & implementation of software systems with desirable internal and external characteristics

§ Desirable: depends on context and objectives § Combinations of characteristics

§ Steps to ensure software quality

§ Identify quality dimensions § Set priorities § Allow (and discuss) tradeoffs § Establish objectives § Establish ways to measure quality

27

slide-20
SLIDE 20

Objectives

§ Many possible dimensions

§ Development time and cost § Code length § Memory usage § Execution speed § …

28

slide-21
SLIDE 21

Quality assurance

§ Implicit and explicit quality assurance steps § Focus here on explicit steps

§ Guidelines for software construction

§ Software process § Follow process

§ Testing strategy § Informal reviews § Formal reviews § External audits

29

slide-22
SLIDE 22

Informal reviews

§ Objective: catch errors early § Misuse of informal reviews

§ Assign blame § Staff evaluation § Budget control

§ Informal

30

slide-23
SLIDE 23

Informal reviews (cont’d)

§ Kinds of informal reviews

1. Inspection

§ Reviewers look at code § Reviewers meet developers, ask questions (person-person interaction)

2. Walk-through

§ Presentation of system § Guide tour by developer(s)

3. Code reading

§ Feedback via comment, review § Usually done by co-developer

31

slide-24
SLIDE 24

Informal reviews

§ Execution of system, test cases may be part of the review

§ Emphasis usually on understanding source code

32

slide-25
SLIDE 25

Inspections

§ Participants with clearly defined roles

§ Some roles mutually exclusive

33

slide-26
SLIDE 26

Roles

§ Moderator

§ Keeps review going § Must be technical person § Neither reviewer nor developer

§ Author

§ Developed software system under review § May start out review with an overview § May answer factual questions (if asked)

§ Explain parts

§ Does not defend decision

§ Do not argue

§ Key is to listen, code should speak for itself

34

slide-27
SLIDE 27

Roles (cont’d)

§ Reviewer(s)

§ Find problems § Identify defects § Find good features § Find good uses

§ Scribe

§ Takes notes § Record defects, problems § Not a reviewer § May also be moderator

35

slide-28
SLIDE 28

Roles (cont’d)

§ Management:

36

slide-29
SLIDE 29

Roles (cont’d)

§ Management: Absent from inspection

§ Inspection is for developers § Objective is not review of developer performance

§ Number of participants

§ At least three: author, reviewer, moderator

§ Moderator and scribe are the same person

§ Large groups more difficult to manage than small ones

40

slide-30
SLIDE 30

Preparation

§ Planning

§ Code or design delivered to moderator § Moderator selects reviewer(s)

§ Setup

§ Overview by developer § Danger: developer “directs” reviewers

§ Preparation

§ Reading of code/design documents

§ Inspection meeting § Inspection report

41

slide-31
SLIDE 31

Follow up

§ Reports state problems § Moderators assign defects for repair

§ May be manager maps requests to developers/authors

§ Another inspection

§ Depends on number and severity of defects

§ Keep logs, collect data

§ Number of defects § Size of software system § Length of meetings § Number of reviewers

42

slide-32
SLIDE 32

Code inspection

§ Well-defined process

§ Even though process is informal § “Homework IV”: Participate in inspection process

§ Review other students’ code § Have your code reviewed § Details later (not today)

§ Process presented here: A possible way to organize reviews

§ Other processes used in practice § A case study: The OpenJDK review process

43

slide-33
SLIDE 33

OpenJDK

§ Open Java Development Kit

§ Free and open-source implementation of the Java Platform

§ Java Platform

§ Java Class Library

§ E.g., packages like java.lang, java.io, java.math

§ (Static) Java compiler javac

§ Translate Java programs → bytecode instructions for Java Virtual Machine

§ HotSpot Java Virtual Machine

§ Just-in-time compilers C1 and C2 (translate bytecode → native code) § Interpreter (template-based) § Runtime system § Garbage collectors

§ …

44

slide-34
SLIDE 34

Quality assurance for OpenJDK (w/ thanks to Z. Majo)

§ “Quality” important

§ Millions of OpenJDK users worldwide

§ Software quality assurance challenging

§ Large codebase: 7 millions of lines of code (Java, C, C++, assembly) § Contributors all around the world

§ In different time zones § Both within Oracle and outside Oracle (volunteers, SAP, RedHat, Intel)

§ Well-defined code review process helps ensure software quality

§ Reviews informal: management is excluded § Other quality assurance methods used as well

§ Only review process discussed today

45

slide-35
SLIDE 35

Workflow for OpenJDK reviews

§ Step 1: Author develops and tests new code

§ Usually results in a patch to the existing system

§ Step 2: Author uploads patch to review server

§ cr.openjdk.java.net § “Webrev”

46

slide-36
SLIDE 36

Webrev

47

slide-37
SLIDE 37

Cdiff

48

slide-38
SLIDE 38

Workflow for OpenJDK reviews

§ Step 1: Author develops and tests new code

§ Usually results in a patch to the existing system

§ Step 2: Author uploads patch to review server

§ cr.openjdk.java.net § “Webrev”

§ Step 3: Author sends out request for review

§ Email to a mailing list § E.g., hotspot-compiler-dev@openjdk.java.net § Usually includes link to webrev, description of problem and solution, testing performed

49

slide-39
SLIDE 39

Workflow for OpenJDK reviews

§ Step 4: Reviewers inspect code, give feedback

§ If changes required, author updates and tests code, continue with Step 2 § Otherwise continue with Step 5

§ Step 5: Code (“change set”) pushed

§ Either by author or by a sponsor

50

slide-40
SLIDE 40

Change sets

§ Code annotated with a well-formed description § Example

8172844: Assert fails in deoptimization due to original PC at the end of code section Summary: Change assert to accept end of code section as well. Reviewed-by: rbackman, kvn, dlong Author: zmajo

§ First line: Unique issue ID (8172844) to identify problem § “Reviewed-by” statement identifies reviewers

§ Give credit to often non-trivial reviewing effort § Reviewers are responsible for havoc if author not available

51

slide-41
SLIDE 41

OpenJDK review process

§ Is it code inspection, walkthrough, or code reading?

§ A combination of all three § It takes elements from each

§ Walkthrough: Author describes problem and solution § Code reading: Reviewers look at code independently

§ Enforced also by geographic distribution § Feedback given in written form (comments)

§ Code inspection: Well-defined roles and steps

52

slide-42
SLIDE 42

Roles

Code inspection (as described earlier)

§ Management not involved § Author § Reviewer(s)

§ Selected by moderator

§ Scribe § Moderator

OpenJDK review process

§ Management not involved § Author § Reviewer(s)

§ Everybody on mailing list

§ Mailing list

§ Log all conversations

§ No moderation

53

slide-43
SLIDE 43

(Lack of) moderation

§ Everybody registered on mailing list can review

§ All members have a right to veto § Though proper justification is always required § Depending on mailing list, 10s or 100s of potential reviewers

§ Making all reviewers happy is sometimes difficult

§ And time consuming

§ Up to 80% of time spent on reviewing

§ Especially if reviewers have conflicting expectations § More the case with cross-component changes

§ E.g., core libraries and JIT compilers

54

slide-44
SLIDE 44

(Lack of) moderation

§ Sometimes (rarely) consensus is not reached

§ Code thrown away

55

slide-45
SLIDE 45

Other differences

§ Suggestions for improvement allowed during OpenJDK reviews

§ Not only defect detection

§ OpenJDK defines a hierarchy of roles

§ Contributor

§ Signed “Oracle Contributor Agreement”

§ Author

§ Person with own username § Listed on project website

§ Committer

§ Allowed to also push code § Can sponsor change sets

§ Reviewer

§ Allowed to decide if code is “good enough”

56

slide-46
SLIDE 46

OpenJDK roles

§ Roles allow fine-grained access control § Achieving ”Reviewer” status

§ Requires 32 “significant” change sets

§ (Author: 2 change sets, Committer: 8 change sets)

§ Through nomination and vote by members

§ All members have the right to veto

§ “Significant”: another vaguely defined word

§ Sometimes: Number of lines of code pushed § Compiler engineer: 1-line change can take weeks to develop

57

slide-47
SLIDE 47

LoC – Lines of Code

§ Aka SLOC – source lines of code § More LoC à more expensive (more time, more effort)

§ Supported by many studies

§ More LoC à better (more functionality, more reliable, …)

§ Numerous counterexamples

§ Never compare metrics for programs written in different languages

58

slide-48
SLIDE 48

hotspot/src/cpu/ppc/vm/stubRoutines_ppc_64.cpp

juint juint* * StubRoutines StubRoutines::ppc64:: ::ppc64::generate_crc_constants generate_crc_constants() { () { juint juint constants[CRC32_CONSTANTS_SIZE] = { constants[CRC32_CONSTANTS_SIZE] = { // Reduce 262144 // Reduce 262144 kbits kbits to 1024 bits to 1024 bits 0x99ea94a8 x99ea94a8UL, UL, 0x00000000 x00000000UL, UL, 0x651797d2 x651797d2UL, UL, 0x00000001 x00000001UL, UL, // x^261120 // x^261120 mod mod p(x)` << 1, x^261184 )` << 1, x^261184 mod mod p(x)` << 1 0x945a8420 x945a8420UL, UL, 0x00000000 x00000000UL, UL, 0x21e0d56c x21e0d56cUL, UL, 0x00000000 x00000000UL, UL, // x^260096 // x^260096 mod mod p(x)` << 1, x^260160 )` << 1, x^260160 mod mod p(x)` << 1 0x30762706 x30762706UL, UL, 0x00000000 x00000000UL, UL, 0x0f95ecaa x0f95ecaaUL, UL, 0x00000000 x00000000UL, UL, // x^259072 // x^259072 mod mod p(x)` << 1, x^259136 )` << 1, x^259136 mod mod p(x)` << 1 0xa52fc582 xa52fc582UL, UL, 0x00000001 x00000001UL, UL, 0xebd224ac xebd224acUL, UL, 0x00000001 x00000001UL, UL, // x^258048 // x^258048 mod mod p(x)` << 1, x^258112 )` << 1, x^258112 mod mod p(x)` << 1 0xa4a7167a xa4a7167aUL, UL, 0x00000001 x00000001UL, UL, 0x0ccb97ca x0ccb97caUL, UL, 0x00000000 x00000000UL, UL, // x^257024 // x^257024 mod mod p(x)` << 1, x^257088 )` << 1, x^257088 mod mod p(x)` << 1 0x0c18249a x0c18249aUL, UL, 0x00000000 x00000000UL, UL, 0x006ec8a8 x006ec8a8UL, UL, 0x00000001 x00000001UL, UL, // x^256000 // x^256000 mod mod p(x)` << 1, x^256064 )` << 1, x^256064 mod mod p(x)` << 1 0xa924ae7c xa924ae7cUL, UL, 0x00000000 x00000000UL, UL, 0x4f58f196 x4f58f196UL, UL, 0x00000001 x00000001UL, UL, // x^254976 // x^254976 mod mod p(x)` << 1, x^255040 )` << 1, x^255040 mod mod p(x)` << 1 0xe12ccc12 xe12ccc12UL, UL, 0x00000001 x00000001UL, UL, 0xa7192ca6 xa7192ca6UL, UL, 0x00000001 x00000001UL, UL, // x^253952 // x^253952 mod mod p(x)` << 1, x^254016 )` << 1, x^254016 mod mod p(x)` << 1 0xa0b9d4ac xa0b9d4acUL, UL, 0x00000000 x00000000UL, UL, 0x9a64bab2 x9a64bab2UL, UL, 0x00000001 x00000001UL, UL, // x^252928 // x^252928 mod mod p(x)` << 1, x^252992 )` << 1, x^252992 mod mod p(x)` << 1 0x95e8ddfe x95e8ddfeUL, UL, 0x00000000 x00000000UL, UL, 0x14f4ed2e x14f4ed2eUL, UL, 0x00000000 x00000000UL, UL, // x^251904 // x^251904 mod mod p(x)` << 1, x^251968 )` << 1, x^251968 mod mod p(x)` << 1 0x233fddc4 x233fddc4UL, UL, 0x00000000 x00000000UL, UL, 0x1092b6a2 x1092b6a2UL, UL, 0x00000001 x00000001UL, UL, // x^250880 // x^250880 mod mod p(x)` << 1, x^250944 )` << 1, x^250944 mod mod p(x)` << 1 0xb4529b62 xb4529b62UL, UL, 0x00000001 x00000001UL, UL, 0xc8a1629c xc8a1629cUL, UL, 0x00000000 x00000000UL, UL, // x^249856 // x^249856 mod mod p(x)` << 1, x^249920 )` << 1, x^249920 mod mod p(x)` << 1 0xa7fa0e64 xa7fa0e64UL, UL, 0x00000001 x00000001UL, UL, 0x7bf32e8e x7bf32e8eUL, UL, 0x00000001 x00000001UL, UL, // x^248832 // x^248832 mod mod p(x)` << 1, x^248896 )` << 1, x^248896 mod mod p(x)` << 1 0xb5334592 xb5334592UL, UL, 0x00000001 x00000001UL, UL, 0xf8cc6582 xf8cc6582UL, UL, 0x00000001 x00000001UL, UL, // x^247808 // x^247808 mod mod p(x)` << 1, x^247872 )` << 1, x^247872 mod mod p(x)` << 1 0x1f8ee1b4 x1f8ee1b4UL, UL, 0x00000001 x00000001UL, UL, 0x8631ddf0 x8631ddf0UL, UL, 0x00000000 x00000000UL, UL, // x^246784 // x^246784 mod mod p(x)` << 1, x^246848 )` << 1, x^246848 mod mod p(x)` << 1 0x6252e632 x6252e632UL, UL, 0x00000000 x00000000UL, UL, 0x7e5a76d0 x7e5a76d0UL, UL, 0x00000000 x00000000UL, UL, // x^245760 // x^245760 mod mod p(x)` << 1, x^245824 )` << 1, x^245824 mod mod p(x)` << 1 0xab973e84 xab973e84UL, UL, 0x00000000 x00000000UL, UL, 0x2b09b31c x2b09b31cUL, UL, 0x00000000 x00000000UL, UL, // x^244736 // x^244736 mod mod p(x)` << 1, x^244800 )` << 1, x^244800 mod mod p(x)` << 1 0x7734f5ec x7734f5ecUL, UL, 0x00000000 x00000000UL, UL, 0xb2df1f84 xb2df1f84UL, UL, 0x00000001 x00000001UL, UL, // x^243712 // x^243712 mod mod p(x)` << 1, x^243776 )` << 1, x^243776 mod mod p(x)` << 1 0x7c547798 x7c547798UL, UL, 0x00000000 x00000000UL, UL, 0xd6f56afc xd6f56afcUL, UL, 0x00000001 x00000001UL, UL, // x^242688 // x^242688 mod mod p(x)` << 1, x^242752 )` << 1, x^242752 mod mod p(x)` << 1 0x7ec40210 x7ec40210UL, UL, 0x00000000 x00000000UL, UL, 0xb9b5e70c xb9b5e70cUL, UL, 0x00000001 x00000001UL, UL, // x^241664 // x^241664 mod mod p(x)` << 1, x^241728 )` << 1, x^241728 mod mod p(x)` << 1 0xab1695a8 xab1695a8UL, UL, 0x00000001 x00000001UL, UL, 0x34b626d2 x34b626d2UL, UL, 0x00000000 x00000000UL, UL, // x^240640 // x^240640 mod mod p(x)` << 1, x^240704 )` << 1, x^240704 mod mod p(x)` << 1 0x90494bba x90494bbaUL, UL, 0x00000000 x00000000UL, UL, 0x4c53479a x4c53479aUL, UL, 0x00000001 x00000001UL, UL, // x^239616 // x^239616 mod mod p(x)` << 1, x^239680 )` << 1, x^239680 mod mod p(x)` << 1 0x123fb816 x123fb816UL, UL, 0x00000001 x00000001UL, UL, 0xa6d179a4 xa6d179a4UL, UL, 0x00000001 x00000001UL, UL, // x^238592 // x^238592 mod mod p(x)` << 1, x^238656 )` << 1, x^238656 mod mod p(x)` << 1 0xe188c74c xe188c74cUL, UL, 0x00000001 x00000001UL, UL, 0x5abd16b4 x5abd16b4UL, UL, 0x00000001 x00000001UL, UL, // x^237568 // x^237568 mod mod p(x)` << 1, x^237632 )` << 1, x^237632 mod mod p(x)` << 1 0xc2d3451c xc2d3451cUL, UL, 0x00000001 x00000001UL, UL, 0x018f9852 x018f9852UL, UL, 0x00000000 x00000000UL, UL, // x^236544 // x^236544 mod mod p(x)` << 1, x^236608 )` << 1, x^236608 mod mod p(x)` << 1 0xf55cf1ca xf55cf1caUL, UL, 0x00000000 x00000000UL, UL, 0x1fb3084a x1fb3084aUL, UL, 0x00000000 x00000000UL, UL, // x^235520 // x^235520 mod mod p(x)` << 1, x^235584 )` << 1, x^235584 mod mod p(x)` << 1 0xa0531540 xa0531540UL, UL, 0x00000001 x00000001UL, UL, 0xc53dfb04 xc53dfb04UL, UL, 0x00000000 x00000000UL, UL, // x^234496 // x^234496 mod mod p(x)` << 1, x^234560 )` << 1, x^234560 mod mod p(x)` << 1 0x32cd7ebc x32cd7ebcUL, UL, 0x00000001 x00000001UL, UL, 0xe10c9ad6 xe10c9ad6UL, UL, 0x00000000 x00000000UL, UL, // x^233472 // x^233472 mod mod p(x)` << 1, x^233536 )` << 1, x^233536 mod mod p(x)` << 1 0x73ab7f36 x73ab7f36UL, UL, 0x00000000 x00000000UL, UL, 0x25aa994a x25aa994aUL, UL, 0x00000000 x00000000UL, UL, // x^232448 // x^232448 mod mod p(x)` << 1, x^232512 )` << 1, x^232512 mod mod p(x)` << 1 0x41aed1c2 x41aed1c2UL, UL, 0x00000000 x00000000UL, UL, 0xfa3a74c4 xfa3a74c4UL, UL, 0x00000000 x00000000UL, UL, // x^231424 // x^231424 mod mod p(x)` << 1, x^231488 )` << 1, x^231488 mod mod p(x)` << 1 0x36c53800 x36c53800UL, UL, 0x00000001 x00000001UL, UL, 0x33eb3f40 x33eb3f40UL, UL, 0x00000000 x00000000UL, UL, // x^230400 // x^230400 mod mod p(x)` << 1, x^230464 )` << 1, x^230464 mod mod p(x)` << 1 0x26835a30 x26835a30UL, UL, 0x00000001 x00000001UL, UL, 0x7193f296 x7193f296UL, UL, 0x00000001 x00000001UL, UL, // x^229376 // x^229376 mod mod p(x)` << 1, x^229440 )` << 1, x^229440 mod mod p(x)` << 1 0x6241b502 x6241b502UL, UL, 0x00000000 x00000000UL, UL, 0x43f6c86a x43f6c86aUL, UL, 0x00000000 x00000000UL, UL, // x^228352 // x^228352 mod mod p(x)` << 1, x^228416 )` << 1, x^228416 mod mod p(x)` << 1 0xd5196ad4 xd5196ad4UL, UL, 0x00000000 x00000000UL, UL, 0x6b513ec6 x6b513ec6UL, UL, 0x00000001 x00000001UL, UL, // x^227328 // x^227328 mod mod p(x)` << 1, x^227392 )` << 1, x^227392 mod mod p(x)` << 1 0x9cfa769a x9cfa769aUL, UL, 0x00000000 x00000000UL, UL, 0xc8f25b4e xc8f25b4eUL, UL, 0x00000000 x00000000UL, UL, // x^226304 // x^226304 mod mod p(x)` << 1, x^226368 )` << 1, x^226368 mod mod p(x)` << 1 0x920e5df4 x920e5df4UL, UL, 0x00000000 x00000000UL, UL, 0xa45048ec xa45048ecUL, UL, 0x00000001 x00000001UL, UL, // x^225280 // x^225280 mod mod p(x)` << 1, x^225344 )` << 1, x^225344 mod mod p(x)` << 1 0x69dc310e x69dc310eUL, UL, 0x00000001 x00000001UL, UL, 0x0c441004 x0c441004UL, UL, 0x00000000 x00000000UL, UL, // x^224256 // x^224256 mod mod p(x)` << 1, x^224320 )` << 1, x^224320 mod mod p(x)` << 1 0x09fc331c x09fc331cUL, UL, 0x00000000 x00000000UL, UL, 0x0e17cad6 x0e17cad6UL, UL, 0x00000000 x00000000UL, UL, // x^223232 // x^223232 mod mod p(x)` << 1, x^223296 )` << 1, x^223296 mod mod p(x)` << 1 0x0d94a81e x0d94a81eUL, UL, 0x00000001 x00000001UL, UL, 0x253ae964 x253ae964UL, UL, 0x00000001 x00000001UL, UL, // x^222208 // x^222208 mod mod p(x)` << 1, x^222272 )` << 1, x^222272 mod mod p(x)` << 1 0x27a20ab2 x27a20ab2UL, UL, 0x00000000 x00000000UL, UL, 0xd7c88ebc xd7c88ebcUL, UL, 0x00000001 x00000001UL, UL, // x^221184 // x^221184 mod mod p(x)` << 1, x^221248 )` << 1, x^221248 mod mod p(x)` << 1 0x14f87504 x14f87504UL, UL, 0x00000001 x00000001UL, UL, 0xe7ca913a xe7ca913aUL, UL, 0x00000001 x00000001UL, UL, // x^220160 // x^220160 mod mod p(x)` << 1, x^220224 )` << 1, x^220224 mod mod p(x)` << 1 0x4b076d96 x4b076d96UL, UL, 0x00000000 x00000000UL, UL, 0x33ed078a x33ed078aUL, UL, 0x00000000 x00000000UL, UL, // x^219136 // x^219136 mod mod p(x)` << 1, x^219200 )` << 1, x^219200 mod mod p(x)` << 1 0xda4d1e74 xda4d1e74UL, UL, 0x00000000 x00000000UL, UL, 0xe1839c78 xe1839c78UL, UL, 0x00000000 x00000000UL, UL, // x^218112 // x^218112 mod mod p(x)` << 1, x^218176 )` << 1, x^218176 mod mod p(x)` << 1 0x1b81f672 x1b81f672UL, UL, 0x00000000 x00000000UL, UL, 0x322b267e x322b267eUL, UL, 0x00000001 x00000001UL, UL, // x^217088 // x^217088 mod mod p(x)` << 1, x^217152 )` << 1, x^217152 mod mod p(x)` << 1 0x9367c988 x9367c988UL, UL, 0x00000000 x00000000UL, UL, 0x638231b6 x638231b6UL, UL, 0x00000000 x00000000UL, UL, // x^216064 // x^216064 mod mod p(x)` << 1, x^216128 )` << 1, x^216128 mod mod p(x)` << 1 0x717214ca x717214caUL, UL, 0x00000001 x00000001UL, UL, 0xee7f16f4 xee7f16f4UL, UL, 0x00000001 x00000001UL, UL, // x^215040 // x^215040 mod mod p(x)` << 1, x^215104 )` << 1, x^215104 mod mod p(x)` << 1 0x9f47d820 x9f47d820UL, UL, 0x00000000 x00000000UL, UL, 0x17d9924a x17d9924aUL, UL, 0x00000001 x00000001UL, UL, // x^214016 // x^214016 mod mod p(x)` << 1, x^214080 )` << 1, x^214080 mod mod p(x)` << 1 0x0d9a47d2 x0d9a47d2UL, UL, 0x00000001 x00000001UL, UL, 0xe1a9e0c4 xe1a9e0c4UL, UL, 0x00000000 x00000000UL, UL, // x^212992 // x^212992 mod mod p(x)` << 1, x^213056 )` << 1, x^213056 mod mod p(x)` << 1 0xa696c58c xa696c58cUL, UL, 0x00000000 x00000000UL, UL, 0x403731dc x403731dcUL, UL, 0x00000001 x00000001UL, UL, // x^211968 // x^211968 mod mod p(x)` << 1, x^212032 )` << 1, x^212032 mod mod p(x)` << 1 0x2aa28ec6 x2aa28ec6UL, UL, 0x00000000 x00000000UL, UL, 0xa5ea9682 xa5ea9682UL, UL, 0x00000001 x00000001UL, UL, // x^210944 // x^210944 mod mod p(x)` << 1, x^211008 )` << 1, x^211008 mod mod p(x)` << 1 0xfe18fd9a xfe18fd9aUL, UL, 0x00000001 x00000001UL, UL, 0x01c5c578 x01c5c578UL, UL, 0x00000001 x00000001UL, UL, // x^209920 // x^209920 mod mod p(x)` << 1, x^209984 )` << 1, x^209984 mod mod p(x)` << 1 0x9d4fc1ae x9d4fc1aeUL, UL, 0x00000001 x00000001UL, UL, 0xdddf6494 xdddf6494UL, UL, 0x00000000 x00000000UL, UL, // x^208896 // x^208896 mod mod p(x)` << 1, x^208960 )` << 1, x^208960 mod mod p(x)` << 1 0xba0e3dea xba0e3deaUL, UL, 0x00000001 x00000001UL, UL, 0xf1c3db28 xf1c3db28UL, UL, 0x00000000 x00000000UL, UL, // x^207872 // x^207872 mod mod p(x)` << 1, x^207936 )` << 1, x^207936 mod mod p(x)` << 1 0x74b59a5e x74b59a5eUL, UL, 0x00000000 x00000000UL, UL, 0x3112fb9c x3112fb9cUL, UL, 0x00000001 x00000001UL, UL, // x^206848 // x^206848 mod mod p(x)` << 1, x^206912 )` << 1, x^206912 mod mod p(x)` << 1 0xf2b5ea98 xf2b5ea98UL, UL, 0x00000000 x00000000UL, UL, 0xb680b906 xb680b906UL, UL, 0x00000000 x00000000UL, UL, // x^205824 // x^205824 mod mod p(x)` << 1, x^205888 )` << 1, x^205888 mod mod p(x)` << 1 0x87132676 x87132676UL, UL, 0x00000001 x00000001UL, UL, 0x1a282932 x1a282932UL, UL, 0x00000000 x00000000UL, UL, // x^204800 // x^204800 mod mod p(x)` << 1, x^204864 )` << 1, x^204864 mod mod p(x)` << 1 0x0a8c6ad4 x0a8c6ad4UL, UL, 0x00000001 x00000001UL, UL, 0x89406e7e x89406e7eUL, UL, 0x00000000 x00000000UL, UL, // x^203776 // x^203776 mod mod p(x)` << 1, x^203840 )` << 1, x^203840 mod mod p(x)` << 1 // //…

59

slide-49
SLIDE 49

Code reviews

§ Good way to assure software quality § Often well-defined process

§ Helps people in organization operate on similar level of standard

§ Defining/following rules

§ Incurs (some) overhead § Keep to minimum

§ Rules should be guided by objectives that matter § Use common sense to find balance

60