ฉันได้อ่านการเขียนโปรแกรมไมโครคอนโทรลเลอร์ PIC แบบ 16 บิตใน Cและมีการยืนยันในหนังสือเล่มนี้:
ในระหว่างการพัฒนาและการดีบักเฟสของโปรเจ็กต์มันเป็นแนวปฏิบัติที่ดีในการปิดใช้งานการปรับให้เหมาะสมทั้งหมดเนื่องจากอาจแก้ไขโครงสร้างของโค้ดที่วิเคราะห์และแสดงปัญหาการวางตำแหน่งจุดพักและเบรกพอยต์แบบเดี่ยว
ฉันสารภาพว่าฉันสับสนเล็กน้อย ฉันไม่เข้าใจว่าผู้เขียนบอกว่าเพราะช่วงเวลาการประเมินC30หรือว่าเป็นการปฏิบัติที่ดีจริงๆ
ฉันต้องการทราบว่าคุณใช้แบบฝึกหัดนี้จริงหรือไม่และเพราะอะไร
คำตอบ:
นี่เป็นมาตรฐานที่ค่อนข้างดีในด้านวิศวกรรมซอฟต์แวร์โดยรวม - เมื่อคุณปรับโค้ดให้เหมาะสมคอมไพเลอร์จะได้รับอนุญาตให้จัดเรียงสิ่งต่าง ๆ ได้อย่างสวยงามอย่างไรก็ตามมันต้องการตราบใดที่คุณไม่สามารถบอกความแตกต่างในการทำงานได้ ตัวอย่างเช่นหากคุณเริ่มต้นตัวแปรภายในการวนซ้ำทุกครั้งของลูปและไม่เคยเปลี่ยนตัวแปรภายในลูปเครื่องมือเพิ่มประสิทธิภาพได้รับอนุญาตให้ย้ายการเริ่มต้นนั้นออกจากลูปดังนั้นคุณจะไม่เสียเวลากับมัน
มันอาจจะรู้ด้วยว่าคุณคำนวณตัวเลขที่คุณไม่ได้ทำอะไรก่อนเขียนทับ ในกรณีนั้นอาจกำจัดการคำนวณที่ไร้ประโยชน์
ปัญหาเกี่ยวกับการปรับให้เหมาะสมคือคุณต้องใส่จุดพักบนโค้ดบางส่วนซึ่งเครื่องมือเพิ่มประสิทธิภาพได้ย้ายหรือกำจัด ในกรณีนั้นดีบักเกอร์ไม่สามารถทำสิ่งที่คุณต้องการได้ (โดยทั่วไปจะทำให้จุดพักใกล้ที่ใดที่หนึ่ง) ดังนั้นเพื่อให้รหัสที่สร้างขึ้นใกล้เคียงกับสิ่งที่คุณเขียนมากขึ้นคุณจะปิดการปรับให้เหมาะสมในระหว่างการดีบั๊กซึ่งทำให้มั่นใจได้ว่ารหัสที่คุณต้องการทำลายมีอยู่จริง
คุณต้องระมัดระวังในเรื่องนี้อย่างไรก็ตามการเพิ่มประสิทธิภาพสามารถทำลายสิ่งต่าง ๆ ได้ทั้งนี้ขึ้นอยู่กับรหัสของคุณ โดยทั่วไปแล้วโค้ดที่ถูกทำลายโดยเครื่องมือเพิ่มประสิทธิภาพการทำงานที่ถูกต้องนั้นเป็นเพียงโค้ดบั๊กกี้ที่หลุดพ้นไปจากบางสิ่งดังนั้นคุณมักจะต้องการทราบสาเหตุที่เครื่องมือเพิ่มประสิทธิภาพแตกหัก
ฉันได้ส่งคำถามนี้ให้ Jack Ganssle และนี่คือสิ่งที่เขาตอบฉัน:
แดเนียล
ฉันชอบที่จะดีบั๊กโดยใช้สิ่งที่การเพิ่มประสิทธิภาพจะอยู่ในรหัสที่ออก นาซ่าบอกว่า "ทดสอบสิ่งที่คุณบินบินสิ่งที่คุณทดสอบ" อย่าทำการทดสอบแล้วเปลี่ยนรหัส!
อย่างไรก็ตามบางครั้งต้องปิดการปรับให้เหมาะสมเพื่อให้ตัวดีบักทำงานได้ ฉันพยายามที่จะปิดพวกเขาในโมดูลที่ฉันทำงานอยู่ ด้วยเหตุนี้ฉันเชื่อในการทำให้ไฟล์เล็กพูดรหัสสองสามร้อยบรรทัดหรือมากกว่านั้น
ทั้งหมดที่ดีที่สุดแจ็ค
ขึ้นอยู่กับและนี่เป็นเรื่องจริงสำหรับเครื่องมือทั้งหมดไม่ใช่แค่ C30
การเพิ่มประสิทธิภาพมักจะลบและ / หรือปรับโครงสร้างรหัสในรูปแบบต่างๆ คำสั่ง switch ของคุณอาจถูกนำมาใช้ใหม่ด้วย if / else construct หรือในบางกรณีอาจถูกลบออกทั้งหมดพร้อมกัน y = x * 16 อาจถูกแทนที่ด้วยชุดของกะซ้าย ฯลฯ แม้ว่าการเพิ่มประสิทธิภาพประเภทสุดท้ายนี้มักจะสามารถก้าวผ่านไปได้ แต่ส่วนใหญ่เป็นการปรับโครงสร้างของคำสั่งควบคุมที่ได้รับยา
สิ่งนี้สามารถทำให้ขั้นตอนดีบักเกอร์ผ่านโค้ด C ของคุณเป็นไปไม่ได้เนื่องจากโครงสร้างที่คุณกำหนดไว้ใน C ไม่มีอยู่อีกต่อไปพวกเขาถูกแทนที่หรือสั่งใหม่โดยคอมไพเลอร์เป็นสิ่งที่คอมไพเลอร์เชื่อว่าจะเร็วขึ้นหรือใช้พื้นที่น้อยลง นอกจากนี้ยังสามารถทำให้เบรกพอยต์เป็นไปไม่ได้ที่จะตั้งค่าจากรายชื่อ C เนื่องจากคำสั่งของคุณอาจไม่อยู่อีกต่อไป ตัวอย่างเช่นคุณอาจลองตั้งค่าเบรกพอยต์ภายในคำสั่ง if แต่คอมไพเลอร์อาจลบว่าถ้า คุณอาจลองตั้งค่าเบรกพอยต์ภายในระยะเวลาหนึ่งหรือเป็นลูป แต่คอมไพเลอร์ตัดสินใจที่จะปลดลูปนั้นดังนั้นจึงไม่มีอยู่อีกต่อไป
ด้วยเหตุผลนี้หากคุณสามารถดีบักโดยปิดการปรับให้เหมาะสมมักจะง่ายกว่า คุณควรทดสอบซ้ำเมื่อเปิดใช้งานการเพิ่มประสิทธิภาพเสมอ นี่เป็นวิธีเดียวที่คุณจะพบว่าคุณพลาดสิ่งสำคัญvolatileและทำให้เกิดความล้มเหลวเป็นระยะ ๆ (หรือความแปลกประหลาดอื่น ๆ )
ในกรณีของการพัฒนาแบบฝังคุณจะต้องระมัดระวังในการปรับให้เหมาะสมอยู่ดี โดยเฉพาะอย่างยิ่งในส่วนของรหัสที่มีความสำคัญต่อเวลาการขัดจังหวะบางอย่างเช่น ในกรณีเหล่านี้คุณควรเขียนรหัสบิตที่สำคัญในแอสเซมบลีหรือใช้คำสั่งคอมไพเลอร์เพื่อให้แน่ใจว่าส่วนเหล่านี้ไม่ได้รับการปรับปรุงเพื่อให้คุณรู้ว่าพวกเขามีเวลาดำเนินการคงที่หรือเวลาทำงานเลวร้ายที่สุด
gotcha อีกตัวสามารถใส่รหัสลงใน uC ได้คุณอาจต้องปรับความหนาแน่นของรหัสให้พอดีกับรหัสของคุณในชิป นี่คือเหตุผลหนึ่งว่าทำไมจึงเป็นความคิดที่ดีที่จะเริ่มต้นด้วยความจุ ROM ที่ใหญ่ที่สุดในครอบครัวและเลือกอันที่เล็กกว่าสำหรับการผลิตหลังจากรหัสของคุณถูกล็อค
โดยทั่วไปฉันจะแก้ปัญหาด้วยการตั้งค่าใด ๆ ที่ฉันวางแผนที่จะปล่อยด้วย ถ้าฉันจะปล่อยรหัสที่ได้รับการปรับปรุงให้ดีที่สุดฉันจะแก้ปัญหาด้วยรหัสที่ได้รับการปรับปรุง หากฉันจะปล่อยรหัสที่ไม่ได้เพิ่มประสิทธิภาพฉันจะดีบักด้วยรหัสที่ไม่ได้เพิ่มประสิทธิภาพ ฉันทำเช่นนี้ด้วยเหตุผลสองประการ. ขั้นแรกเครื่องมือเพิ่มประสิทธิภาพสามารถสร้างความแตกต่างของเวลาได้อย่างมากพอที่จะทำให้ผลิตภัณฑ์สุดท้ายทำงานแตกต่างจากรหัสที่ไม่ได้เพิ่มประสิทธิภาพ ประการที่สองแม้ว่าส่วนใหญ่จะค่อนข้างดีผู้ขายคอมไพเลอร์ทำผิดพลาดและรหัสที่ได้รับการปรับปรุงสามารถสร้างผลลัพธ์ที่แตกต่างจากรหัสที่ไม่ได้เพิ่มประสิทธิภาพ เป็นผลให้ฉันต้องการได้รับเวลาทดสอบมากที่สุดเท่าที่จะเป็นไปได้ด้วยการตั้งค่าใด ๆ ก็ตามที่ฉันวางแผนจะปล่อยด้วย
ดังที่กล่าวมาเครื่องมือเพิ่มประสิทธิภาพสามารถทำการดีบักได้ยากดังที่ระบุไว้ในคำตอบก่อนหน้า หากฉันพบส่วนของรหัสที่ยากต่อการดีบักฉันจะปิดเครื่องมือเพิ่มประสิทธิภาพชั่วคราวทำการดีบักเพื่อให้รหัสทำงานได้จากนั้นเปิดเครื่องมือเพิ่มประสิทธิภาพอีกครั้งและทดสอบอีกครั้ง
กลยุทธ์ปกติของฉันคือการพัฒนาด้วยการเพิ่มประสิทธิภาพขั้นสุดท้าย (สูงสุดสำหรับขนาดหรือความเร็วตามความเหมาะสม) แต่พลิกการเพิ่มประสิทธิภาพออกชั่วคราวถ้าฉันต้องการดีบัก ot ติดตามบางสิ่งบางอย่าง สิ่งนี้จะช่วยลดความเสี่ยงของการเกิดข้อผิดพลาดอันเป็นผลมาจากการเปลี่ยนระดับการเพิ่มประสิทธิภาพ
โหมดความล้มเหลวทั่วไปคือเมื่อการเพิ่มประสิทธิภาพที่เพิ่มขึ้นทำให้เกิดข้อผิดพลาดที่มองไม่เห็นก่อนหน้านี้เนื่องจากคุณไม่ได้ประกาศตัวแปรว่ามีความผันผวนตามความจำเป็น - นี่เป็นสิ่งสำคัญที่จะบอกคอมไพเลอร์ว่า
ใช้รูปแบบใดก็ตามที่คุณจะปล่อยพร้อมตัวดีบั๊กและรวบรวมสำหรับการดีบักซ่อนข้อบกพร่องจำนวนมาก (มาก) ที่คุณไม่เห็นจนกว่าคุณจะรวบรวมเพื่อเผยแพร่ จากนั้นจะเป็นการยากที่จะหาข้อบกพร่องเหล่านั้นเทียบกับการดีบักตามที่คุณไป 20 ปีที่แล้วและฉันไม่เคยใช้ gdb หรืออื่น ๆ เช่น debugger ไม่จำเป็นต้องดูตัวแปรหรือขั้นตอนเดียว หลายร้อยถึงหลายพันสายต่อวัน ดังนั้นจึงเป็นไปได้อย่านำไปคิดอย่างอื่น
การคอมไพล์สำหรับดีบักจากนั้นการคอมไพล์สำหรับการรีลีสในภายหลังและอาจต้องใช้ความพยายามมากกว่าสองเท่า หากคุณเข้าสู่การเชื่อมโยงและต้องใช้เครื่องมือเช่นดีบักเกอร์ให้รวบรวมเพื่อให้ดีบักเกอร์ทำงานผ่านปัญหาที่เฉพาะเจาะจงจากนั้นย้อนกลับสู่การทำงานปกติ
ปัญหาอื่น ๆ ก็เป็นจริงเช่นกันที่เครื่องมือเพิ่มประสิทธิภาพทำให้โค้ดเร็วขึ้นดังนั้นสำหรับการฝังตัวในเวลาของคุณด้วยตัวเลือกคอมไพเลอร์และอาจส่งผลกระทบต่อการทำงานของโปรแกรมของคุณที่นี่อีกครั้งใช้ตัวเลือกการคอมไพล์ คอมไพเลอร์ก็เป็นโปรแกรมเช่นกันและมีบั๊กและเครื่องมือเพิ่มประสิทธิภาพทำผิดและบางคนไม่มีความเชื่อในเรื่องนั้น หากเป็นกรณีที่ไม่มีอะไรผิดปกติกับมันรวบรวมโดยไม่มีการเพิ่มประสิทธิภาพเพียงทำอย่างนั้นตลอดเวลา เส้นทางที่ฉันชอบคือการรวบรวมเพื่อการปรับให้เหมาะสมแล้วถ้าฉันสงสัยว่าปัญหาคอมไพเลอร์ปิดการใช้งานการเพิ่มประสิทธิภาพหากการแก้ไขนั้นมักจะไปกลับไปกลับมาบางครั้งตรวจสอบเอาท์พุทแอสเซมเบลอร์เพื่อหาสาเหตุ
ฉันมักจะพัฒนารหัสด้วย -O0 (ตัวเลือก gcc เพื่อปิดการเพิ่มประสิทธิภาพ) เมื่อฉันรู้สึกว่าฉันอยู่ในจุดที่ฉันต้องการเริ่มปล่อยให้สิ่งต่าง ๆ มุ่งไปสู่การวางจำหน่ายมากขึ้นฉันจะเริ่มต้นด้วย -Os (ปรับขนาดให้เหมาะสม) โดยทั่วไปยิ่งคุณใส่รหัสในแคชมากเท่าไรก็ยิ่งดีเท่านั้น แม้ว่ามันจะไม่ได้รับการปรับให้เหมาะสมสูงสุด
ฉันพบว่า gdb ทำงานได้ดียิ่งขึ้นด้วยรหัส -O0 และง่ายต่อการติดตามถ้าคุณต้องก้าวเข้าสู่การชุมนุม การสลับระหว่าง -O0 และ -Os ยังช่วยให้คุณเห็นว่าคอมไพเลอร์กำลังทำอะไรกับโค้ดของคุณ บางครั้งมันก็เป็นการศึกษาที่น่าสนใจและยังสามารถค้นพบข้อบกพร่องของคอมไพเลอร์ ... สิ่งที่น่ารังเกียจเหล่านั้นที่ทำให้คุณดึงผมออกไปลองคิดดูว่ามีอะไรผิดปกติกับรหัสของคุณ!
ถ้าฉันต้องการจริงๆฉันจะเริ่มเพิ่มใน -fdata-section และ -fcode-section ด้วย --gc-section ซึ่งอนุญาตให้ linker ลบฟังก์ชั่นและส่วนข้อมูลทั้งหมดที่ไม่ได้ใช้จริง มีหลายสิ่งเล็ก ๆ น้อย ๆ ที่คุณสามารถทำให้คนจรจัดลองลดขนาดให้เล็กลงหรือทำสิ่งต่าง ๆ ให้เร็วขึ้น แต่โดยมากแล้วสิ่งเหล่านี้เป็นเพียงกลวิธีเดียวที่ฉันใช้และสิ่งใดก็ตามที่ต้องเล็กลง -assemble
ใช่การปิดใช้งานการปรับให้เหมาะสมระหว่างการแก้ไขข้อบกพร่องเป็นแนวปฏิบัติที่ดีที่สุดมาระยะหนึ่งแล้วด้วยเหตุผลสามประการ:
หลายคนไปให้ดียิ่งขึ้นต่อไปในทิศทางนี้และ เรือที่มีการยืนยันเปิด
ง่าย: การปรับให้เหมาะสมนั้นใช้เวลามากและอาจไร้ประโยชน์หากคุณต้องเปลี่ยนรหัสนั้นในภายหลังในการพัฒนา ดังนั้นพวกเขาอาจเสียเวลาและเงิน
มีประโยชน์สำหรับโมดูลที่เสร็จสมบูรณ์อย่างไรก็ตาม ส่วนของรหัสที่ส่วนใหญ่อาจไม่ต้องการการเปลี่ยนแปลงอีกต่อไป
แน่นอนว่ามันสมเหตุสมผลในกรณีของจุดพัก ... เนื่องจากคอมไพเลอร์สามารถลบข้อความมากมายที่ไม่มีผลต่อความจำ
พิจารณาสิ่งที่ชอบ:
int i =0;
for (int j=0; j < 10; j++)
{
i+=j;
}
return 0;อาจถูกปรับให้เหมาะสมทั้งหมด (เพราะiไม่เคยอ่าน) มันจะมองจากมุมมองของจุดพักของคุณว่ามันข้ามรหัสทั้งหมดเมื่อมันโดยทั่วไปไม่ได้อยู่ที่นั่น .... ฉันคิดว่านั่นเป็นเหตุผลว่าทำไมฟังก์ชั่นประเภทสลีปคุณมักจะเห็นสิ่งต่อไปนี้:
for (int j=delay; j != 0; j--)
{
asm( " nop " );
asm( " nop " );
}
return 0;หากคุณใช้ดีบักเกอร์ฉันจะปิดใช้งานการปรับให้เหมาะสมและเปิดใช้งานการดีบัก
โดยส่วนตัวแล้วฉันพบว่าตัวดีบัก PIC ทำให้เกิดปัญหามากกว่าที่จะช่วยฉันแก้ไข
ฉันเพิ่งใช้ printf () เพื่อ USART เพื่อดีบักโปรแกรมของฉันที่เขียนใน C18
ข้อโต้แย้งส่วนใหญ่เกี่ยวกับการเปิดใช้งานการเพิ่มประสิทธิภาพในการรวบรวมของคุณมาที่:
IMHO สองคนแรกนั้นถูกกฎหมายคนที่สามไม่มากนัก บ่อยครั้งหมายความว่าคุณมีรหัสที่ไม่ดีหรือพึ่งพาการใช้ภาษา / การใช้งานที่ไม่ปลอดภัยหรือผู้เขียนอาจเป็นแฟนของพฤติกรรมที่ไม่ได้กำหนดของลุง
บล็อก Embedded in Academia มีสิ่งหนึ่งหรือสองอย่างที่จะพูดถึงเกี่ยวกับพฤติกรรมที่ไม่ได้กำหนดและโพสต์นี้เป็นวิธีที่คอมไพเลอร์ใช้ประโยชน์จากมัน: http://blog.regehr.org/archives/761