1 / 41

מבנה מחשבים ספרתיים 234267

מבנה מחשבים ספרתיים 234267. זכרון מטמון מבוסס על תרגול של מורן גביש, חלק מהשרטוטים עפ"י ליהוא רפפורט, רנדי כץ, פטרסון ( C ) Yohai Devir November 2005 Updated by Franck Sala. מהירות הגישה לזיכרון איטית ביחס לביצועי המעבד (עד פי 1000), ככל שהזיכרון גדול יותר הגישה אליו איטית יותר.

hans
Download Presentation

מבנה מחשבים ספרתיים 234267

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. מבנה מחשבים ספרתיים234267 זכרון מטמון מבוסס על תרגול של מורן גביש, חלק מהשרטוטים עפ"י ליהוא רפפורט, רנדי כץ, פטרסון (C) Yohai Devir November 2005 Updated by Franck Sala

  2. מהירות הגישה לזיכרון איטית ביחס לביצועי המעבד (עד פי 1000), ככל שהזיכרון גדול יותר הגישה אליו איטית יותר. ביצועי המעבד נפגעים משמעותית אם בכל קריאה מהזיכרון יש להמתין (ולהשבית את המעבד) מספר רב של מחזורי שעון. • הבעיה הפתרון החזקת עותק חלקי של הזכרון "קרוב" למעבד כך שזמן הגישה אליו יהיה קצר בהרבה.

  3. למה הפתרון הזה טוב? • מקומיות בזמן – אם ניגשנו לאובייקט מסויים, סביר להניח שניגש אליו שוב בקרוב. • אנו מבלים 90% מהזמן ב- 10% מהקוד – בעקר עקב לולאות בהן קוראים אותה שורה מספר פעמים. • משתנים מסוימים מעודכנים פעם אחר פעם. לדוגמא – מיון. • מקומיות במקום – אם ניגשנו לאובייקט מסויים, סביר להניח שניגש לאובייקטים סמוכים אליו. • קטעי קוד, סביר מאד שנצטרך גם את הפקודה הבאה ואילו שאחריה. • נתונים – אם קראנו (או כתבנו) ממקום אחד במערך סביר להניח שנקרא (או נכתוב) גם את סביבתו. תזכורת לחוק אמדל – עדיף לשפר את מה שקורה רוב הזמן !

  4. טרמינולוגיה • פגיעה (Hit) • הנתון מופיע ברמת הזכרון. • החטאה (Miss) • הנתון לא מופיע ברמת הזיכרון ולכן צריך להביאו מרמה נמוכה יותר. • יחס פגיעה (hit rate) • אחוז הפגיעות מתוך סה"כ הגישות לזכרון. • Miss rate = 1 – hit rate • בלוק • הזכרון המרכזי מחולק לבלוקים של מספר בתים. בכל פעם שנצטרך להעתיק בית למטמון נעתיק את כל הבלוק בו הוא נמצא.

  5. 31 4 0 Tag = Block# Line Offset Data array Tag Array Line Tag Fully associative Organization 1. נחלק את שדה כתובת המידע למספר הבלוק (tag – מספר זיהוי) ולמיקום המידע בתוך הבלוק (offset). 2. המטמון יהיה בנוי כטבלה של מספר הבלוק ו- תוכן הבלוק. כל בלוק בזכרון יכול להכנס לכל שורה במטמון.

  6. Fully associative Organization Address Fields 31 4 0 Tag = Block# Line Offset Tag Array Data array Line Tag = = = 31 0 Hit\Miss data

  7. Fully associative Organization Block 1 Block 2 כל בלוק בזכרון יכול להתמפות לכל שורה במטמון. Data array Tag Array Block m Line Tag : : Block n • יתרון: Hit Rate גבוה. • חסרון: מימוש ההשוואה המקבילית קשה ויקר.

  8. מדיניות פינוי במטמון יהיו הרבה פחות שורות מאשר בלוקים בזכרון הראשי כאשר יש צורך להביא בלוק נוסף למטמון יהיה צורך לזרוק את אחד הבלוקים הקודמים. יש מספר אפשרויות לבחור מי יהיה הבלוק שייזרק: • LRU - least recently used • הבלוק שזמן רב ביותר לא השתמשנו בו (לקריאה או לכתיבה). • LRM - least recently modified • הבלוק שזמן רב ביותר לא כתבנו אליו. • Random • בחירה אקראית לחלוטין.

  9. Direct Mapping Organization 1. נחלק את שדה כתובת המידע למיקום המידע בתוך הבלוק (offset) ואת מספר הבלוק נחלק למיקום במטמון (set) ולמספר זיהוי (tag). Block number 31 8 7 4 0 5 Tag Set Line Offset 2. המטמון יהיה בנוי כטבלה של מספר הבלוק ו- תוכן הבלוק. Tag Line Set# Tag Array Cache storage ההבדל ממבנה של fully associative cache הוא שהפעם לכל שורה במטמון יש מספר מזהה – set.

  10. Direct Mapping Organization 3. מציאת הנתון: א. נמצא את השורה המתאימה עפ"י ה- set כאינדקס במערך. ב. נשווה את ה- tag של הכתובת עם ה- tag של השורה במטמון אליה הצביע ה- set. במידה ויש התאמה הבלוק המבוקש נמצא במטמון. אחרת יש החטאה וצריך להביא את הבלוק. ג. במידה והנתון נמצא במטמון, ניגש ל- byte המתאים בשורה עפ"י שדה ה- disp. Block number 31 13 4 0 5 Tag Line Offset Set Tag Line 29 =512 sets Set# Tag Array 31 Cache storage 0

  11. block 0 (set = 00) block4 (set = 00) block4n (set = 00) block2 (set = 10) block6 (set = 10) block4n+2 (set = 10) Direct Mapping Organization כל שורה בזכרון יכולה להמצא בשורה אחת במטמון. שימו לב שאין צורך במדיניות פינוי! Cache Size Cache Size tag Data Set# 00 01 10 11 . . . . יתרון: קל למימוש וזול חסרון:miss rate גבוה שנובע משיטת המיפוי המאפשרת מיפוי של מספר כתובות (בעלות סיביות set זהות) לאותה שורה במטמון. Cache Size

  12. Block number 31 6 4 0 5 Tag Set Line Offset 2 way set associative Organization 1. באופן זהה ל- direct mappingנחלק את שדה כתובת המידע למיקום המידע בתוך הבלוק (offset) ואת מספר הבלוק נחלק למיקום במטמון (set) ולמספר זיהוי (tag). 2. המטמון יהיה בנוי כשתי טבלאות של מספר הבלוק ו- תוכן הבלוק. WAY 0 WAY 1 Tag Line Tag Line Set# Tag Array Cache storage Tag Array Cache storage ההבדל ממבנה של direct mapping הוא שהפעם יש שני ways, כל אחד בנוי כמו direct mapping כאשר הנתון יכול להמצא בכל אחד מהם.

  13. Data = = MUX Hit/Miss 2 way set associative Organization 3. מציאת הנתון: א. נמצא את השורה המתאימה עפ"י ה- set כאינדקס במערך. ב. נשווה את ה- tag של הכתובת הדרושה עם ה- tag של השורה במטמון אליה הצביע ה- setבכל אחד מה- ways. במידה ויש התאמה הבלוק המבוקש נמצא במטמון. אחרת יש החטאה וצריך להביא את הבלוק. ג. במידה והנתון נמצא במטמון, ניגש ל- byte המתאים בשורה עפ"י שדה ה- disp. 31 6 5 4 0 Tag Set Line Offset Way 1 Way 0 Tag Tag Data Set# Set# Data Out

  14. 0 (set = 00) 4 (set = 00) 4n (set = 00) 2 (set = 10) 6 (set = 10) 4n+2 (set = 10) tag tag Data Data 2 way set associative Organization כל שורה בזכרון יכולה להמצא בשורה אחת במטמון באחד משני ה- ways. ע"מ לממש LRU מספיק ביט אחד לכל set. Cache Size Cache Size WAY 0 WAY 1 Set# 00 01 10 11 Set# 00 01 10 11 . . . . יתרון / חסרון: השיטה של k-ways מהווה פשרה סבירה, אופטימלית בביצועים. Cache Size

  15. 31 31 4 5 3 4 2 2 1 1 0 0 Tag Tag Set Set Line Offset Line Offset K way set associative Organization נניח מטמון בעל קיבולת של 8 בלוקים (DATA) 4 בתים כ"א ואסוציאטיביות משתנה 2 way set associative 1 way set associative (direct mapping) WAY 0 WAY 1 tag Data tag Data tag Data Set# 000 001 010 011 100 101 110 111 Set# 00 01 10 11

  16. 31 3 2 1 0 Tag Set Line Offset 31 2 1 0 Tag Line Offset K way set associative Organization (II) 4 way set associative WAY 0 WAY 1 WAY 2 WAY 3 Set# 0 1 tag Data tag Data tag Data tag Data 8 way set associative WAY 1 WAY 7 WAY 0 tag Data tag Data tag Data . . . tag Data זהו בעצם fully associative mapping רק מצוייר לרוחב...

  17. 31 3 2 1 0 Tag Set Line Offset K way set associative Organization (III) נניח מטמון בעל אסוציאטיביות של 4 ונפח data משתנה 4 בלוקים WAY 0 WAY 1 WAY 2 WAY 3 tag Data tag Data tag Data tag Data 31 2 1 0 Tag Line Offset 8 בלוקים WAY 0 WAY 1 WAY 2 WAY 3 Set# 0 1 tag Data tag Data tag Data tag Data

  18. 31 31 5 4 4 3 2 2 1 1 0 0 Tag Tag Set Set Line Offset Line Offset K way set associative Organization (IV) 16 בלוקים WAY 0 WAY 1 WAY 2 WAY 3 Set# 00 01 10 11 tag Data tag Data tag Data tag Data 32 בלוקים WAY 0 WAY 1 WAY 2 WAY 3 tag Data tag Data tag Data tag Data Set# 000 001 010 011 100 101 110 111

  19. מטמון היררכי • עד כה דברנו על מבנה זכרון היררכי בעל מטמון יחיד (רגיסטרים – מטמון – זכרון ראשי – דיסק). היות וישנם נתונים הנקראים בתכיפות רבה מאוד ונתונים שנקראים בתכיפות רבה אך נמוכה יותר, יש הגיון ביצירת מספר היררכיות של זכרון מטמון, כאשר הרמה הראשונה (L1) קטנה ומהירה מהרמה שמתחתיה (L2). במידה והנתון לא נמצא ברמה מסויימת, תשלח בקשת קריאה לרמה שמתחתיה. CPU Registers L1 Cache Multi level Cache L2 Cache L3 Cache Main Memory Disk Backup

  20. עקרון ההכלה • במטמון ההיררכי שעובד לפי עקרון ההכלה כל רמה של הזכרון ההיררכי מכילה את כל הנתונים שנמצאים ברמה שמעליה. • הדבר נועד ע"מ לפשט את הפרוטוקולים של התקשורת בין רמה לרמה. העקרון לא מתקיים בכל המעבדים.

  21. שאלה I • במחשב C123 הותקנה היררכית זיכרון המכילה 3 רמות של cache, המשמרות את עקרון ההכלה, כמתואר בשרטוט הבא: CPU Registers L1 Cache L2 Cache L3 Cache Main Memory ה- CPU יזם קריאה מכתובת m. בקשה זאת גררה שרשרת ארועים בשלושת המטמונים. אילו מהאירועים הבאים אפשריים, אילו לא ולמה? כל האירועים מתוארים לפי סדר: קודם ב- L1 אח"כ L2 ובסוף ב- L3. M=Miss H=Hit ומשבצת ריקה מסמלת שלא קרה דבר (כלומר לא בוצעה פניה למטמון הזה(.

  22. עדכון למטמוןWrite Back : • נניח שיש צורך לעדכן נתון מסויים. במידה והנתון נמצא במטמון, עפ"י עקרון ההכלה, ישנם מספר עותקים של הנתון במספר רמות. ישנן שתי אפשרויות עיקריות לטיפול במקרה זה: • בזמן כתיבה נרשום רק לרמה הדרושה. העדכון לשאר הרמות יבוצע כאשר הנתון ייזרק מהמטמון. • על מנת לבצע מדיניות זאת לכל בלוק תשמר סיבית מיוחדת dirtyשתהווה אינדיקציה האם הבלוק עודכן וטרם נכתב לרמת זכרון נמוכה יותר. • כאשר נתבקש לפנות בלוק מסוים, נעדכן בלוק זה ברמת הזכרון הנמוכה יותר במידה וסיבית ה- dirty דולקת. • בכל עדכון נצטרך לעדכן את כל הבלוק מכיוון שסיבית ה- dirty מוחזקת עבור הבלוק כולו ולא עבור byte מסויים. פינוי מקום לנתון אחר כתיבה L1 L2 הציור – עבור מטמון (fully associative, 2 מילים בבלוק) בעל שתי רמות שפועלות במדיניות כתיבה writeback.

  23. עדכון למטמוןWrite Through : • מדיניות נוספת למקרה בו יש צורך לעדכן נתון שנמצא במטמון היא מדיניות Write through • בזמן כתיבה נרשום את הערך החדש של הנתון גם לרמה שמתחתיו • כאשר הנתון ייזרק מהמטמון, אין צורך לעדכן את הרמה שמתחתיו פינוי מקום לנתון אחר כתיבה L1 L2 הציור – עבור מטמון (fully associative, 2 בתים בבלוק) בעל שתי רמות שפועלות במדיניות כתיבה write through. שימו לב! בשיטת write through אין צורך בסיבית dirty (למה ?) סיבית סטטוס נוספת שנמצאת עבור כל בלוק במטמון (בד"כ ללא קשר למדיניות) היא סיבית Valid. בלוק שנמצא במצב I (Invalid) הוא בלוק שבו המידע שנמצא בשורת ה- data אינו משקף את המידע שנמצא בבלוק בעל tag מתאים ברמות נמוכות יותר.

  24. כתיבה למטמוןWrite Allocate: • נניח שיש צורך לעדכן נתון מסויים שלא נמצא במטמון • ע"מ לשמור על עקרון ההכלה, ישנן שתי אפשרויות עיקריות לטיפול במקרה זה: • Write allocate • במקרה של החטאה מורידים לרמה שמתחת בקשה להבאת הבלוק. • טרם הבאת הבלוק מהרמה התחתונה מפנים את המקום המתאים (מבחינת set ומדיניות החלפה). בקשת כתיבה, החטאה ופינוי מקום הבאת הבלוק וכתיבה L1 L2 הציור – עבור מטמון (fully associative, 2 בתים בבלוק) בעל שתי רמות שפועלות במדיניות כתיבה writeback ומדיניות write miss של Write allocate.

  25. כתיבה למטמוןNo Write Allocate : • מדיניות נוספת למצב של החטאת כתיבה היא No Write allocate • במקרה של החטאה מורידים לרמה שמתחת את בקשת הכתיבה עצמה. אין הבאה של הבלוק לרמה הנדרשת. בקשת כתיבה מרמה 1לרמה 2, פגיעה בקשת כתיבה לרמה 1, החטאה L1 L2 הציור – עבור מטמון (fully associative, 2 בתים בבלוק) בעל שתי רמות שפועלות במדיניות כתיבה write through ומדיניות write miss של No Write allocate ברמה הראשונה.

  26. שאלה I (2) • תזכורת – מדובר במעבד עם 3 רמות של זכרון מטמון ששומרות על עקרון ההכלה. • עם העברת בקשת קריאת תוכן כתובת m נוצרה במטמונים שרשרת אירועים במהלכה נדרש מטמון L3 לפנות אחת מהשורות שלו אל הזכרון הראשי • הנח שלכל המטמונים אותו גודל שורה וכולם מאורגנים ב- K-way. כמו כן הנח שכל המטמונים היו מלאים בעת בקשת הקריאה. Request to read address M  L3 victimizes an entry to main memory מה היה המצב בהיררכיית המטמונים שהוביל לצורך בהחלפת שורה ב- L3? תשובה: אם יש צורך להחליף שורה ב- L3 מכאן שהיו 3 החטאות בכל שלוש הרמות של המטמון.

  27. שאלה I (3) • Snoop • - snoop the caches above when an entry is victimized in order to keep inclusion • במקרה שרמת מטמון מסויימת רוצה למחוק נתון מסוים היא "מסתכלת" על הדרגה שמעל ובודקת האם הנתון נמצא גם שם, ואם כן יש למחוק אותו קודם כדי לשמור על עקרון ההכלה. תאר (באופן איכותי) את שהתרחש מרגע גילוי הצורך בהחלפת השורה ב- L3 ועד התייצבות תוכן היררכיית הזיכרון ומסירת תוכן כתובת m למעבד (קרי – עד למאוחר שבין שני אירועים אלו). What happens from L3 victimization? ניתן להניח שכל המטמונים עובדים לפי מדיניות write-back, מדיניות LRU ושומרים על עקרון ההכלה.

  28. שאלה I (4) • L1 מזהה read miss ומבקש את הנתון ממטמוןL2 • L2 מזהה read miss ומבקש את הנתון ממטמוןL3 • L3 מזהה read miss ובוחר שורה להחלפה • Snoops: • מבצע snoop אל L2 כדי לבדוק אם עותק של שורה זאת נמצא אצלו • אם יש עותק של השורה המוחלפת ב- L2, L2 מבצע snoop אל L1 • אם יש עותק של השורה המוחלפת ב- L1: • אם העותק במצב M (modified), L1 כותב אותו אל L2. • בכל מקרה, L1 מסמן את השורה הנ"ל כפנוייה (מצב I – Invalid). • אם יש עותק של השורה המוחלפת ב- L2: • אם העותק במצב M (modified), L2 כותב אותו אל L3. • בכל מקרה, L2 מסמן את השורה הנ"ל כפנוייה (מצב I – Invalid). • אם השורה המתפנה מ- L3 היא במצב M, L3 כותב אותה לזכרון הראשי ומסמן את השורה הזאת כפנויה (מצב I).

  29. שאלה I (5) • L3 קורא את השורה הנדרשת (החדשה) מהזכרון הראשי ומעדכן LRU. • במידה ויש מקום פנוי ב-L2 ב- set הרלוונטי, L2 קורא את השורה הנדרשת מ- L3 אל אחת השורות הפנויות ב- set המתאים ומעדכן LRU. • במידה ואין מקום פנוי, L2 בוחר שורה לפנות, מבצע snoop & Invalidate ל- L1 (כולל כתיבה של המידע מרמה L1 לרמה L2 במקרה של dirty), ורושם את המידע לרמה L3 במידה והשורה הנ"ל מסומנת אצלו כ- dirty. לאחר שפונה מקום מתאים, הנתון נכתב ל- L2, ומעודכן LRU. • במידה ויש מקום מתאים ב- L1, L1 קורא את השורה הנדרשת מ- L2 אל אחת השורות הפנויות ב- set המתאים ומעדכן LRU. • במידה ואין מקום מתאים, מפונה אחת השורות (נכתבת לרמה L2 במידה ובמצב dirty), מעתיק את הנתון מרמה L2 ומעדכן LRU.

  30. L1 L2 L3 Rd Req Rd Request Rd Request M: read miss M: read miss M: read miss Select victim: P Snoop Request Snoop P Snoop P Yes: WrReq HIT P dirty? P dirty? P HIT Yes: WrReq Yes: WrReq no no P dirty? no Update P Invalidate P Invalidate P Invalidate P yes Free entry Fill Data Fill M victim: X Update LRU Fill Data Snoop X X dirty? … … Fill M &Update LRU Snoop + Fill M &Update LRU

  31. שאלה I (6) • מה היה ההבדל אם לא היה צריך לשמור על עקרון ההכלה? תשובה: היינו מבצעים קריאה ישירות למטמון L1.

  32. שאלה I (7) • נתון כי מטמונים L2 ו- L3 פועלים בעת write miss במדיניות no write allocate (כלומר, במקרה של החטאה בקשת הכתיבה מועברת לרמה הבאה). • בשלב מסויים בצע המעבד כתיבה לכתובת n. בקשה זו גררה שרשרת ארועים בהיררכיית הזכרון אשר נפתחה ב- write miss במטמון L1 ובמהלכה (של שרשרת הארועים) פונתה שורה ממטמון L3. • L2/L3: no write allocate • Write to n • Write miss in L1 • An entry in victimized in L3 שאלה: מהי מדיניות ה- write miss של מטמון L1? תשובה: מדיניות write miss של L1 היא write allocate, אחרת לא היה צורך לקרוא שורות למטמון ולפנות שורה מ- L3. (הוכחה על דרך השלילה) שאלה: האם יתכן שיתרחש במעבד C123 אירוע מסוג L2 write miss? אם כן – באילו סיטואציות? תשובה: לא. עקב עקרון ההכלה לא יתכן write miss באחת הרמות התחתונות בלי שיהיה write miss ב- L1. כל write miss ב- L1 שהוא write allocate גורר בקשת קריאה (כלומר line fill) מ- L1 אל L2, מכיוון שאנחנו שומרים על עקרון ההכלה, לא יתכן write miss ב- L2. בגלל ש L1 במדיניות write-allocate וע"ס עקרון ההכלה אין משמעות לעובדה ש- L2 ו- L3 במדיניות no-write-allocate מכיוון שלא יתכן בהם write miss.

  33. שאלה II • נתון מטמון בעל המאפיינים הבאים: • גודל (data area) – 64 בתים. • מספר בלוקים – 16 • אורך כתובת לגישה – 30 סיביות. • ארגון 2 way set associative. • לכל בלוק מוצמדות גם סיביות valid ו- dirty. • מדיניות החלפת בלוקים – LRU • א. כמה סה"כ סיביות זכרון מכיל המטמון? • Data: 64 byte / 16 blocks • Addr: 30 bits • 2 ways – LRU • Valid + dirty

  34. data: 64 byte / 16 blocks • Addr: 30 bits • 2 ways – LRU • Valid + dirty שאלה II (2) Tag Set offset 29 5 4 2 1 0 • 64 byte / 16 blocks  block is 4 bytes  Disp: 2 bits • 2 ways / 16 blocks  8 sets  Set: 3 bits • Addr = 30 bits  Tag: 30 -3-2= 25bits • LRU for 2 ways: 1 bit per set • Cache size = data size + (tag + valid + dirty)* #blocks + LRU * #sets = 64*8 + ( 25 + 1 + 1 ) * 16 + 1 * 8 = 952 bits

  35. שאלה II (3) מהי מדיניות הכתיבה ומדוע ניתן להניח כך? Tag Set offset 29 5 4 2 1 0 מדיניות הכתיבה היא write back, ניתן להניח כך משום שיש ביטdirty. למטמון בעל מדיניות כתיבה אחרת אין צורך בביט זה, שתפקידו הוא לסמן האם יש לעדכן את השורה בזכרון הראשי כאשר יהיה צורך לפנותה מהמטמון. • למטמון הנתון נשלחה סדרת הכתובות הבאה (גישה לבתים): • Addresses: 5 7 1 4 36 8 100 6 4 12 36 12 68 5 7 • בהנחה שמדיניות הפינוי היא LRU והמטמון מלא ב- data של בלוקים שאינם מופיעים בסדרה דלעיל מצא: • כמה החטאות יווצרו? • מה מכיל המטמון בתום הסדרה (קרי – אילו בלוקים בכל set)? כדי לפתור את השאלה נצטרך לחשב לאיזה set במטמון נכניס את הבלוק המבוקש מהזכרון הראשי. את שדה ה- set ניתן לחשב לפי Set = floor(ADDRESS / line length) mod (lines per way) הסבר: חלוקת הכתובת ב- 4 (אורך השורה) תוריד את שדה ה- offset, וביצוע mod8 יתן את שלושת סיביות ה- LSB של מספר הבלוק שהן בעצם ה- set.

  36. שאלה II (5) Way 1 Way 0 29 5 4 3 2 1 0 • Physical memory divided into 4 segments: A0 B0 A1 B1 (256MB each – 28 bit address) - • A000.... (30 bit address) • B001…. • A110…. • B111…. • 50% of the cache for segments A – 50% of the cache for segments B • Solution: • Change the mapping function so that the sets [0:3] will contains data for segments A, and [4:7], data for segment B Original mapping: Tag Set offset New mapping: 29 28 4 3 2 1 0 Set[2] Tag Set[1:0] offset

  37. שאלה II (6) המטמון דלעיל שובץ במחשב בו מרחב הזיכרון הפיסי מחולק לארבעה סגמנטים זרים שווים בגודלם ( MB 256 כל אחד), A0B0A1B1 לפי סדר זה. למתכנן המטמון הוצבה דרישה לפיה לא ייוצר מצב שיותר מ- 50% מהמטמון יכיל כתובות של סגמנטי A או סגמנטי B ועם זאת תישמר שיטת 2way. הצע דרך פשוטה ויעילה למימוש דרישה חדשה זו מה- cache והסבר את פעולתה. נשים לב כי ה- MSB של כל סגמנט מוגדר באופן הבא: A0???..00 B0 ..???01 A1???..10 B1 ..???11 ספרת ה- 2nd MSB עבור סגמנטי A היא תמיד 0, ואילו עבור סגמנטי B היא תמיד 1. נדאג למפות את המטמון כך שארבע השורות העליונות ימופו תמיד אך ורק לכתובות מסגמנטי A, ואילו ארבע בתחתונות לכתובות מסגמנטי B, ע"י שימוש בביט הנ"ל שנקרא לו ביט הסגמנט. תוצאה זאת נשיג באמצעות שינוי פונקציית המיפוי (שדה ה- set) במקום שיכיל את 3 סיביות LSB של מספר הבלוק (mod8), נשתמש ב- שתי סיביות LSB בלבד ובסיסית הסגמנט. מיפוי ישן: DDSSSTTTTT TTTTTTTTTTTTTTTTTTTT מיפוי חדש: DDTSSTTTTT TTTTTTTTTTTTTTTTSTTT

  38. שאלה II (6) 29 28 4 3 2 1 0 Set[2] Tag Set[1:0] offset

More Related