Lampson-Hints - 8/1/11 Click to edit Master subtitle style...

Info iconThis preview shows pages 1–11. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: 8/1/11 Click to edit Master subtitle style Hints for Computer Design Travis McVey, Diego Velasquez, Mark Whylie, Drem Darios, Elroy Ashtian Jr. 8/1/11 HINTS FOR COMPUTER Members of the group Part of the paper Diego Velasquez Introduction Drem Darios Functionality (From 2.1 to 2.3) Elroy Ashtian Jr Functionality (From 2.4 to 2.5) Travis McVey Speed Mark Whylie Fault Tolerance Diego Velasquez Conclusion Outline: 8/1/11 Section 1 Introduction By: Diego Velasquez 8/1/11 Introduction  Abstract: Paper based in the experienced of Butler W. Lampson. General hints for computer system design illustrated using examples. 8/1/11 Introduction  Points explain in the paper: Designing a computer system is different from designing an algorithm. There is no a best way to build a system. They are just hints The hints are illustrated by a number of examples. They range from: hardware, operating systems, programming systems, and applications programs. 8/1/11 Introduction  Each hint is summarized by a slogan.  The following table organizes the slogans in two Why? where? Functionality Does it work? Speed Is it fast enough? Fault-tolerance Does it keep working? Completeness Separate normal and worst case Safety first Shed load End-to end End-to-end Interface Do one thing well: Dont Generalize Dont hide power Use procedure arguments Leave it to the client Keep basic interfaces stable Keep a place to stand Make it fast Split Resources Static Analysis Dynamic translation End-to-end Log Updates Make action atomic Implementation Plan to throw one away Cache answers Make action atomic 8/1/11 Section 2 Functionality Section 2.3 By: Drem Darios 8/1/11 Click to edit Master subtitle style Functionality The most vague but most important hint is to obtain the right functionality for a system. Interface design must satisfy three things: It should be simple It should be complete, meaning normal and worst cases are considered It should admin a sufficiently small and fast implementation 8/1/11 Car Example Driving Operate Car Brake Pedal Brake Controller Brake Line Brake s Accele rator Throttle Controller Fuel Engin e Steerin g Wheel Steering system Steerin g Colum n Wheel Angle User Program Interfa Devic es Softw are Hardware Abstract Interface Device Interface Modules Hardware Interface 8/1/11 Keep it simple Do one thing and do it well When an interface undertakes too much it results in a large, slow, and complicated implementation Some interfaces are ok to sacrifice performance for functionality Get it right!...
View Full Document

Page1 / 45

Lampson-Hints - 8/1/11 Click to edit Master subtitle style...

This preview shows document pages 1 - 11. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online