קרנל ו-++C...

[MotiAd]

קרנל ו-++C...

היי חברה. התחלתי לממש את המע"ה שלי ב-++C לעת עתה. רציתי לשאול אם יש הצדקה לעניין חוץ מהקטע המודולרי ושהכל מסודר בצורה של OO. זה נחמד ויפה אבל השאלה היא אם למשל אני עושה שימוש באחד מהמיכלים הסטנדרטיים של ++C נניח ווקטור או מילון(אני לא חושב שזה קיים שם אבל אל תתפסו אותי במילה, זה רק לשם הדוגמא) אז הכל יעבוד פיקס ללא שום מודול נפרד? לא צריך לספק כלום? או שאני צריך לממש רשימה בעצמי, נניח לייצוג של כל התהליכים שפועלים במערכת? שלכם, מוטקלה. ד"א אני מתכוון להעלות את המודולים לכאן עוד מעט (ימים אולי שבועות) לאחר שהייצוג יסתיים כדי שתבחנו ותגידו מה דעתכם.

 

[voguemaster]

מוטי...

אף קרנל קיים לא מסתמך על ספריות. כל דבר שיש בקרנל הוא קוד של הקרנל וממומש בתוך הקרנל. אם נניח אתה רוצה לממש רשימה או MAP כך שיהיה לך זמן גישה לוגריתמי בעזרת איזה מבנה נתונים (נדמה לי ש-set ו-map של STL ממומשות ע"י red-black tree) אתה חייב לכתוב את זה בעצמך כחלק מהקרנל או להעתיק מימוש חופשי כלשהו ולשלב אותו בתוך הקרנל. אני לא בטוח ש ++C היא השפה המתאימה לכתיבת קרנלים וקוד ברמת קרנל אבל אין לי ניסיון בזה אז... אני לא אתן נימוקים מלבד זה שהקרנל של לינוקס כתוב ב-C והוא קרנל....

 

[annefan]

זה נכון אבל...

דווקא המיכלים ממומשים כ-templates, מה שאומר שהם מוכללים בקבצי קוד, ומקומפלים כל פעם (עזוב PCH כרגע) סטטית בתוך הקובץ. השאלה היא מה הם מביאים איתם. יותר מזה, ב-C יש ספרית newlib שהיא תת-קבוצה של הספריה הסטנדרטית של C, שמתאימה למערכות embedded (בלי float לדוגמא, אם לא צריך). בקרנל עצמו יש גרסה חלקית של הספריה הסטנדרטית. אולי יש משהו כזה גם ל-++C? לגבי הבחירה ב-++C, לינוס שחרר קרנל ב-++C. הוא ירד מהרעיון בגלל שלטענתו הקומפיילרים של ++C היו חדשים מדי, ושהוא וידידיו לא ידעו מה הם באמת עושים לקוד. לא נראה לי שהנימוק הזה תקף גם היום. מה שכן, כיוון שביצועים חשובים מאד, צריך להיזהר מכל מיני פינות. גם לזה הספר "Efficient C++" יעזור לך מאוד.

 

[MotiAd]

תודה רבה לשניכם!!!...

אני אקרא את הספר ששלחת לי אלי על הקרנל של לינוקס. וגם את הספר Efficient ++C. תודה רבה. אני אבדוק בקטע הזה. מה שאמרת לגבי המיכלים נכון נזכרתי עכשיו. פשוט נוצרת גירסה של הפונקציה לכל פעם שיש סוג משתנה חדש (זה לא מנוסח נכון אבל הכוונה מובנת) וזה נכנס לקוד. תודה רבה שוב.

 

[MotiAd]

אני מניח שזה יהיה טוב כדי...

לתת לי מבט כללי על העסק הזה של הקרנל ואח"כ להעביר אותו לאסמבלי. נראה מה יהיה. בלי ספק מימוש ב-C הוא יותר קל. אבל ב-++C זה קצת יותר מודולרי עם מחלקות. בלי שטיקים מעצבנים כאלו (איתחולים ובלגאנים עם מצביעים, סתם סתם) יותר כיף לעבוד ולבדוק את המערכת ואח"כ נמיר אותה למימוש יותר טוב. שאלה נוספת שלי שאני מתחבט בה נכון לעכשיו היא האם לשלב פונקציות לטיפול בגרפיקה כחלק מהקרנל? (כמעט כמו GDI אבל ממש לא מורכב כמוהו, נניח פונקציות לציור קו, אליפסה, עיגול וכו') שלכם, מוטי.

 

[annefan]

שתי שאלות

א. למה להעביר את הקרנל לאסמבלי? מה רע ב-C? ב. למה לדחוף פונקציות גרפיקה לקרנל? מה הוא עשה רע?

 

[MotiAd]

חחחחח....

אין שום רע ב-C. הקטע של אסמבלי הוא רק בשביל המוח (או הכיף) וגם בשביל הניסיון והעוצמה. הקרנל האמת לא עשה שום רע. אבל זה סוג של גישה אני לא יודע. אף אחד לא אמר שקרנל צריך רק לטפל בהחלפה של תהליכים (סתם בשביל ההגזמה) אבל אני בודק כל מיני רעיונות חדשים. אתה צודק בעיקרון. הקרנל חף מפשע. הדרך הכי טובה לעשות את זה היא בצורה של לינוקס. כמו מודולים נטענים כאלה. לא חלק אינטגרלי אבל כשצריך אותם הם נטענים. אפשר לעשות את זה להרבה מודולים (לאו דווקא רשת, מדיה נשלפת וכו'). בקיצור שווה מחשבה. תודה על ההארה (בכוונה מנוסח כך). שלך, מוטי.

 

[annefan]

אם כבר אז כבר

אם אסמבלי עושה לך טוב ואתה יודע שקומפיילרים של C יכולים ליצור קוד מצוין, לך על זה. לגבי הקרנל, הגישה של לינוקס היא לא הגישה הנכונה היחידה. הקרנל שם הוא מונוליתי, עם אפשרות לטעינת מודולים. יש גם קרנלים בגישה של micro-kernel וכל השאר בחוץ, כמו Mach, עליו מתבססת OSX של מק. בהצלחה רבה.

 

[voguemaster]

בעיניי ++C קלה יותר

בהכל. מצד שני, לא הייתי מנסה לכתוב קרנל ב ++C.

 

[אלדד28]

למה לא?

++C איטית יותר מ-C, גם אחרי השימוש בכל כללי האצבע של ++Efficient C, אבל הפרש המהירות הוא כל כך מזערי שאני לא חושב שיש הצדקה אמיתית לכתיבה בשפה פרוצדורלית. ++C עם שילוב של אסמבלי במקומות הנכונים נראה לי אולטימטיבי. רוב המשחקים היום כתובים כך - למה לא קרנלים?

 

[voguemaster]

כמו שאמרתי

אין לי ניסיון בכתיבת קרנלים ואין לי מושג מה ה-pitfalls האפשריים ואיך זה ישפיע אם הקוד ייכתב ב ++C. גם ככה התמיכה בסטנדרט היא לא משהו בקומפיילרים אז נראה לי שתהיה בעיה לעשות את זה. תחשוב שקרנל כמו של לינוקס שאמור להתקמפל על כמה פלטפורמות יתקמפל ב- ++C לא בצורה פורטבילית לגמרי...

 

[אלדד28]

למה שזה ישפיע?

לגבי הסטנדרט, זה טיעון לא רלוונטי. יש כך וכך דברים שלא נתמכים באי אילו קומפיילרים, ופשוט לא משתמשים בהם.

 

[eyalbd]

יש לך אי דיוק

תנאי הכרחי שהקרנל של לינוקס יתקמפל בארכיטקטורה מסויימת הוא שיהיה GCC לאותה מכונה. ואם משתמשים בקומפיילר אחד אז שיקול הפורטביליות פחות חשוב.

 

[voguemaster]

אבל..

לא כל קרנל מקמפלים עם GCC. אולי את של לינוקס כן באופן מסורתי. אבל, זהלא מחייב

 

[eyalbd]

במה ++C יותר איטית?

סתם מיתוס.

 

[אלדד28]

זה לא מיתוס.

קרא את ++Efficient C, ותראה שלמרות ש - ++C מגיעה קרוב מאוד ל-C, היא עדיין יותר איטית. הסיבה לכך היא פשוטה - ++C יוצרת OVERHEAD, איך שלא תסתכל על זה, בקוד עצמו. אם היית מממש את כל ה-FEATURE-ים של ++C בעצמך ב-C, היית מקבל קוד איטי הרבה יותר מזה הנוצר אוטומטית לפי ++C, אבל אם אתה לא צריך את ה-FEATURE-ים האלו (כמו CTOR, DTOR, או VTBL וכו') - אז זה סתם OVERHEAD שנוסף לך לעסק. נכון, 99% מהדברים אפשר לנטרל בשימוש נכון בשפה, אבל לא הכל. חוץ מזה, השאלה היא איך אתה משתמש בשפה. אם תשתמש ב-string במקום ב-* char, התוכנית שלך תהיה הרבה יותר יפה, אבל פחות מהירה. אם תשתמש ב-stream-ים במקום להשתמש ב-sprintf, אותו דבר - התוכנית תהיה יותר יפה ופחות מהירה. אם לא תשתמש בכל הדברים האלו, אז לא ממש עברת ל - ++C.

 

[roterl]

אתם מפספסחם פה משהו נוסף

חלק נכבד מהספריות של C++ נשענות על פונקציות של המערכת, וכאשר כותבים מערכת קצת בעיה להשתמש בהם...

אכן C++ יותר איטית, וגם הקובץ המקומפל גדול יותר, ומה לעשות - כאשר קותבים קרנל מהירות וגודל הם הגורם הכי משמעותי. וגם אם ניתן להתגבר על הבדלי הביצועים בעזרת כתיבה נכונה, ואם לא משתמשים ב OO (שהוא לוקח משאבים גדול) וכו, וכו.. אז מה ההבדל כבר מלכתוב ישירות ב C ?

 

[אלדד28]

לא מדויק.

ראשית, זה לא רק "ספריות ++C", אלא גם "ספריות C". ה-CRT נשענת על קריאות מערכת (או שלא), ולכן זה לא רלוונטי. שנית, OO הוא לא לוקח משאבים גדול. הוא מאט את התוכנה, אבל לא משמעותית. כמו שאמרתי קודם בשרשור, ++C איטית יותר מ-C, אבל לא ברמה משמעותית - והיתרונות שלה גדולים מאוד ביחס לחסרונות.

 

[MotiAd]

או קיי...

אז אני לא מתכוון לקמפל את הקרנל ב-++C אלא רק ליצור בה את המראה הכללי. כמובן שאני אקמפל כדי לבחון איך מה ולמה בשלבים מסויימים אבל בסוף הכל עובר לאסמבלי. כי נכון לעכשיו זה די מעצבן לבנות את הכל באסמבלי כי ב-C ו-++C אפשר לבנות דברים בצורה יותר מודולרית. יותר נחמד לשכל ולעצבים. כי להתחיל לבנות מבנים ולבנות מחלקות שיתבססו על המבנים האלו, אמנם זה לא בשמיים בכלל, אבל את התיכנון אני מעדיך לעשות ב-C או ++C. אם ישלמישהו הצעות אחרות אני אשמח. מה גם שאני משתמש ב-GGC כדי ליצור קוד אסמבלי מהמודולים שאני כותב ב-++C חוקר אותו ומשפר (תמיד יש מה - JMP מיותר או כל דבר אחר או מכניס קוד עם חישוב של נקודה צפה או SSE (משהו shiny כזה) סתם). זה כלי נחמד לעבוד איתו. חוץ מזה ברגע שעובדים על לינוקס/יוניקס GCC ו-NASM תומכים בכל מיקרו בקר שיצא מעולם (אפילו דברים שאני לא שמעתי אליהם) בין היתר מעבדים של מוטורולה וכו. מוטי.

 

[roterl]

אם אתה מתכוון לשכתב לאסמבלי

אז עדיף לך לכתוב ב C - היא יותר קרובה לאסמבלי