อีกประเด็นน่าสนใจใน การเปิดตัวซีพียูใหม่ของ Arm ประจำปี 2023 คือซีพียูของปี 2023 เป็นแบบ 64 บิตล้วน ไม่มี 32 บิตแล้ว
บริษัท Arm มีสถาปัตยกรรม 64 บิตเรียกว่า AArch64 หรือ ARM64 มาตั้งแต่ปี 2011 (ยุค ARMv8) แต่ตลอดสิบกว่าปีที่ผ่านมายังเป็นการใช้งานควบคู่กับ 32 บิต (AArch32)
Arm เริ่มเปลี่ยนผ่านสู่โลกยุค 64-bit only อย่างช้าๆ เริ่มจาก ซีพียูตัวใหญ่ Cortex-X2 ในปี 2021 และในปีที่แล้ว เริ่มเปลี่ยนซีพียูไซส์กลาง Cortex-A715 เป็น 64 ล้วน แต่ไม่ได้ออกซีพียูไซส์เล็กตามมาด้วย (ยังใช้ Cortex-A510 รุ่นของปี 2021) โดยมีผู้ผลิตมือถือบางรายที่ออกแบบซีพียูเอง เช่น Google Pixel 7 เลือกใช้คอร์ 64 บิตล้วน
ปีนี้ Arm ออกซีพียูไซส์เล็กตัวใหม่ Cortex-A520 ที่เป็น 64 บิตล้วนเรียบร้อยแล้ว การเปลี่ยนผ่านเสร็จสมบูรณ์ ทำให้มือถือที่เลือกใช้ชิป Arm ของปี 2023 จะเป็น 64 บิตล้วนตามไปด้วยทันที (ปีนี้คงได้เห็นกันเยอะเลย)
ข้อดีของการใช้ซีพียู 64 บิตคือรองรับหน่วยความจำขนาดใหญ่ขึ้น ส่วนการใช้ 64 บิตล้วนก็ช่วยลดความซับซ้อนของการมี 2 สถาปัตยกรรมลงมา พื้นที่ในซีพียูว่างเยอะขึ้นเพราะไม่ต้องมีรีจิสเตอร์ 32 บิตอีกต่อไป ฝั่งของซอฟต์แวร์นั้นพร้อมมานานแล้ว โดย Android รองรับ 64 บิตมาตั้งแต่เวอร์ชัน 5.0 และฝั่งแอพก็มี นโยบาย Google Play ตั้งแต่ปี 2021 ที่จะหยุดส่งแอพ 32 บิตให้มือถือ 64 บิต นอกจากนี้ Arm ยังให้ข้อมูลว่าตลาดแอพสโตร์ฝั่งจีนปรับมาเป็นแอพ 64 บิตล้วนแทบ 100% แล้ว
Comments
เหล่า Android emulator ต่าง ๆ เหงื่อตกกันแน่นอน
ถ้าพวกเจ้าดังๆไม่น่าเหงื่อตกครับ เพราะทำรองรับ 64bit รอไว้แล้ว เมื่อถึงเวลาจริงๆก็เปลี่ยนได้เลย จะเหลือก็แต่พวกเกมบางเกมที่อาจมีปัญหากับ Emulator บางเจ้า เมื่อใช้งานบนระบบ 64bit ครับ
แค่มนุษย์คนนึงที่อยากรู้เกี่ยวกับวงการไอที
ถ้าแอพบางตัวยัง 32bit อยู่ จะมี emulator มาช่วยใหม หรือต้อง recomplie เป็น 64bit อย่างเดียว
ความล้มเหลว คือจุดเริ่มต้นสู่ความหายนะ มีผลกระทบมากกว่าแค่เสียเงิน เวลา อนาคต และทรัพยากรที่เสียไป - จงอย่าล้มเหลว
บน Android พวก App ใหม่ ๆ ไม่มี 32-bit แล้วครับ โดนบังคับให้เป็น 64-bit ตั้งแต่ 2021 หมดแล้ว และเหมือนว่าถ้า app ไหนไม่ได้ update เกินกำหนด ก็จะถูกเอาออกจาก store ครับ
แต่ถ้าจะถามถึง app เดิมที่ลงอยู่แล้วละก็ อันนั้นคือลงอยู่ในเครื่องเดิมที่ support 32-bit อยู่ ไม่เกี่ยวกับ chip ใหม่ที่จะมีแต่ 64-bit ครับ
แต่จริง ๆ ผู้พัฒนา app แค่เอามา recompile ก็จะได้เป็น 64-bit อยู่แล้วครับ (ถ้าไม่เขียนอะไรที่แปลกประหลาดมาจนใช้งานไม่ได้)
ลองอ่านจาก ข่าวนี้ ดูครับ
พัฒนาเร็วดีน ะ
128 บิตจะมีไหมนะอนาคต 5555
มือใหม่!! ใหม่จริงๆนะ
ต้องให้มี requirement เกิน 16 Exbibytes RAM ก่อนครับ
เคยมีซีพียูที่เรียกตัวเองว่าเป็น 128-bit อยู่ครับ (แต่ส่วนใหญ่จะเป็นพวก SIMD มากกว่า)
ผมว่า ณ.จุดนี้ความจำเป็นที่จะต้องรองรับ operand ใหญ่ระดับนั้นมันมีน้อยนะ และก็พอใช้ 64-bit operation ทำงานแทนได้ถึงจะช้ากว่าก็ตาม
จะไป Quantum แทนเปล่าครับ
ปกติแล้วโค้ด 32bit มันรันบน 64bit ไม่ได้เหรอครับ แล้วบน windows นี่เขาทำยังไงอะครับรันผ่าน emu อีกทีเหรอ
The Dream hacker..
มีส่วน x86 ที่เป็น 32-bit บน CPU เลย
ลองย้อนไปดูข่าวไม่นานนี้ครับ ที่ Intel ก็จะถอด 32-bit ออกเหมือนกันhttps://www.blognone.com/node/133922
การเปลี่ยนผ่านจาก 32+64bit ไป 64-bit only บนอุปกรณ์พกพาทำได้ง่ายกว่า เพราะ legacy app น้อยกว่าครับ (จะโดน OS บังคับให้เป็น 64-bit มาสักพักแล้ว) แต่สำหรับ Intel ที่มี OS หลัก ๆ อย่าง Windows อันนี้ก็จะลำบากหน่อย เพราะทั้ง legacy driver, legacy application เยอะครับ แต่เอาเข้าจริง ๆ ก็จะมีผลเฉพาะ CPU ใหม่เท่านั้น สำหรับ user เดิมที่ใช้บนเครื่องเดิม ๆ ไม่ได้กระทบอะไร
เพราะว่าในมุมมองของ Consumer มันเป็นแบบนั้น คอมพิวเตอร์จึงต้องปรับตัวตาม
ในทางสถาปัตยกรรมของหน่วยประมวลผลแล้วจะรองรับหนึ่งสถาปัตยกรรมเท่านั้น และหากต้องการประมวลผลเลขที่ยาวกว่าหรือสั้นกว่าที่รองรับ โปรแกรมเมอร์ต้องพลิกแพลงเอาเองจากที่มีอยู่ แต่หน่วยประมวลผลก็สามารถออกแบบให้มีโหมดของการประมวลผลที่ต่างกันออกไปได้ "ซึ่งผู้ใช้ต้องการ" ในอดีต 8088 ที่ใช้ในคอมพิวเตอร์ IBM PC เคยเป็น 8 บิตมาก่อน แล้วมันขยายมา 80186 กลายเป็น 8 บิต และ 16 บิตอยู่ด้วยกัน จากนั้นยุค 386 ก็มาเป็น 8 + 16 + 32 บิต ซึ่งสลับโหมดเอาว่าอยากใช้บิตโหมดเท่าไรและสลับตอนไหนก็ได้ แล้วมาเป็น 486 และ Pentium ดังนั้นเขาเลยเรียกซีพียูนี้แบบรวม ๆ ว่า x86 ในทางเทคนิคมันลึกกว่านี้มากแต่เอาเป็นว่าซีพียูมันทำได้ ด้วยเหตุผลที่ว่าต้องรองรับซอฟต์แวร์ยุคเก่า จนมาถึงยุค 64 บิต ซึ่งมันก็เป็นตัวต่อยอดขึ้นไปอีกเช่นกัน มันเลยถูกเรียกเป็น x86_64 โดยที่ 64 คือตัวต่อยอดการประมวลผล 64 บิตบนชิป x86
แต่การทำแบบนี้ก็มีปัญหาในตัวของมันเหมือนกัน เพราะเมื่อต้องรวมชุดคำสั่งเข้ามาก ๆ ก็ทำให้ตัวชิปมันบวมขึ้น และใช้พลังงานสูงขึ้นตามไปด้วย และเป็นเหตุผลว่าทำไมชิป x86_64 ส่วนใหญ่จึงต้องการระบบระบายความร้อนที่ดี และเป็นเหตุผลให้ชิปอื่น ๆ ยุคหลังที่พัฒนามาตั้งแต่รากฐานพยายามใช้สถาปัตยกรรมเดียว ซึ่งก็จะก่อปัญหาด้านการรองรับซอฟต์แวร์ไปด้วย อย่าง Itanium ฉีกชาวบ้าน รองรับสถาปัตยกรรมเดียว (64 บิต ถ้าจะใช้ 32 คือต้องผ่าน emulation) ผลคือตายคาที่ ผู้พัฒนาจำนวนน้อยรายที่คิดเข้ามาแจมด้วย
เข้าเรื่องกันเลยดีกว่า ฝั่งของ ARM เองเริ่มมาที่ 16 บิต และแม้ว่า ARM ได้ถูกจัดหมวดเป็น Reduced Instruction Set Computer (RISC) แต่ทางปฏิบัติแล้ว ARM เพิ่มฟีเจอร์ได้ค่อนข้างอิสระ และชุดคำสั่งต่าง ๆ ก็มักจะเก็บความต้องการดั้งเดิมไว้ด้วย ชิป ARM 32 บิตก็เคยเก็บโหมด 16 บิตไว้จนกระทั่งคนไม่ต้องการอีกต่อไปจึงเอาออก ของชิป ARM64 ก็เช่นกัน สามารถรันซอฟต์แวร์ 32 บิตบนชิป 64 บิตได้ และด้วยความที่มันมีข้อได้เปรียบจากการเป็นชิปมือถือ และ OS เจ้าต่าง ๆ ก็มี policy ที่ชัดเจนในการเปลี่ยนผ่านสถาปัตยกรรมที่ชัดเจน ทำให้มันพัฒนาตัวเองขึ้นมาได้ง่าย ทิ้งของเก่า ๆ ได้เร็ว
และมีความน่าจดจำที่น้อยกว่า PC แบบมหาศาล อย่างเหล่าเกมกาชาควรลงนรกไปได้แล้วฉะนั้น Microsoft และ x86 จึงเป็นของที่คู่กัน เพราะได้ชื่อเสียงจากการรองรับของเก่า ๆ โดยที่ไม่ต้องทำอะไรมาก แต่มันก็เป็นตัวฉุดรั้งไม่ให้มันพัฒนาได้เร็วเช่นกัน จนตอนนี้ Microsoft ยังเจอปัญหาการรองรับซอฟต์แวร์ข้ามสถาปัตยกรรม เพราะนอกจากปัญหาไดรเวอร์แล้ว ในบางครั้งที่ในบางซอฟต์แวร์ดันไปใช้ชุดพัฒนาที่ต้องการชุดคำสั่งที่ไม่มีอยู่ในซีพียูของ Host ทำให้มันไม่สามารถรันได้ตามปกติ และนอกจาก Microsoft แล้ว Intel/AMD ก็โดนไปด้วย จะเพิ่มความสามารถอะไรเพิ่มเติมเข้าไปก็ยากลำบาก ติดที่ของเก่าตลอด อย่าง Intel ก็เคยเสนอไอเดียในการเอาชุดคำสั่งเก่า ๆ ออกให้หมดแล้ว ตอนนี้ก็ต้องรอดูต่อไปว่าจะเหมาะสมหรือไม่ แล้วมีทางแก้ในการรองรับซอฟต์แวร์เก่า ๆ มาไว้แล้วหรือยัง
ผมว่ามันก้าวข้ามอะไรยากมาก แค่ TPM ยังบ่นกันระนาวเลย
รันไม่ได้ครับ คือตัว 32-bit/64-bit ที่ว่า มันคือขนาดของ cpu word ซึ่งมีขนาดตายตัว ถ้าเราเอาชุดคำสั่งของ 32-bit ใส่เข้าไปในซีพียู 64-bit จะกลายเป็นว่าสองคำสั่งจะถูกยุบเหลือคำสั่งเดียว และอาจจะเป็นคำสั่งที่ผิดได้ด้วยครับ
นึกสภาพว่าเหมือนตอนเราชงชา แล้วเราตักน้ำตาลด้วยช้อนโต๊ะ แทนที่จะเป็นช้อนชาน่ะครับ
ในกรณีของ x86-64 ตัวมันจะมี mode 32bit (x86) กับ 64bit(AMD64) เป็นสองโหมดแยกกัน ตัวแอพลิเคชั่นจะรันที่โหมดไหนขึ้นอยู่กับว่า build มาเป็นโหมดไหน ผมเข้าใจว่าสลับโหมดได้ด้วยคำสั่งที่เป็นภาษาเครื่อง (แต่อาจจะเข้าใจผิดครับ) ตัวโอเอสเองก็สามารถสลับโหมดไปมาเวลารันชุดคำสั่งจากโปรแกรมที่เป็นคนละชุดคำสั่งได้
ถ้าสังเกตดี ๆ ตัว Windows เองจะมากับ dll สองชุด ชุดทีเ่ป็น x86 กับชุดที่เป็น x86-64 ครับ เพราะโปรแกรมภายนอกเองก็สามารถ Build มาเป็นตัวใดตัวนึงในนี้ก็ได้นั่นเอง
แต่ถ้าเป็นซีพียูที่มีแต่ 64-bit word ล่ะก็ มันก็จะไม่รู้ว่าเออชุดคำสั่งนี้เป็น 32-bit นะ
ทีนี้ ตัวซีพียูเองจริง ๆ มันไม่ได้ทำงานกับ opcode/machine language ตรง ๆ แต่มันจะแปลไปเป็นภาษาที่ต่ำกว่า ในกรณีนี้ไม่ว่าชุดคำสั่งที่ส่งเข้ามาจะเป็น x86 หรือ AMD64 มันก็จะถูกแปลมาเป็นคำสั่งของซีพียูโดยตัวซีพียูเองอีกทีนึง (micro opcode มั้ง ผมลืมละเค้าเรียกว่าอะไร) ดังนั้นมันจึงสามารถทำงานไม่ว่าจะเป็นชุดคำสั่งไหนก็ตามครับ (ตราบใดที่ตัว decode รู้จักชุดคำสั่งที่ว่า)
ผมเดาว่าถ้าเรายกเลิกการรองรับชุดคำสั่ง 32-bit ก็คือการไปแก้ decoder ให้ถอดการรองรับชุดคำสั่ง 32-bit และการสลับโหมดไปมาระหว่างสองตัวนี้ครับ
ทั้งนี้คือ ... เอ่อ ... รอผู้เชี่ยวชาญมาให้ข้อมูลเพิ่มดีกว่าครับ 555
เสริมให้อีกนิด ใน binary ของ OS ส่วนใหญ่จะมี identifier ของสถาปัตยกรรมอยู่ด้วย ทำให้ OS รู้ได้เลยว่าตัวเองเอามารันได้หรือไม่ หรือว่าตัวเองมี Translation Layer (กรณีที่รองรับ) อยู่ด้วยหรือไม่ ถ้ารันไม่ได้ก็ kick out ได้ทันที ไม่ต้องทำอะไรต่อ
อันนี้ถูกต้อง เครื่องสามารถสลับโหมดได้ในระหว่างนั้นเลย ทำให้ไบนารี 32 บิตรันบน 64 บิตได้ (จริง ๆ ควรเรียกว่าสลับจาก 32 ไป 64 มากกว่า ใน x86_64 เรียกว่า long mode) แต่ก็มีบางกรณีที่สลับไม่ได้ เช่น Real Mode และ Protected Mode (ตอนที่รัน 8 ไป 16 บิต) ตรงนี้ต้องเลือกอย่างใดอย่างหนึ่งแล้วทำงานไปตลอด ไม่อย่างนั้นระดับการเข้าถึงหายไป แต่ปัจจุบันแทบจะถูกลืมไปแล้วเพราะไม่มีความจำเป็นอีกต่อไป และเครื่องx86_64 ใหม่ ๆ ก็ถอดความสามารถ 16 บิตออกไปกันแทบจะหมดแล้ว หรือต่อให้มีอยู่ก็ใช้ไม่ได้ใน long mode
ตรงนี้ไม่ถูก 100% ตัวที่ไม่ได้ทำงานตรง ๆ คือ syscall ที่ต้องแปลงอีกทีหนึ่งไปตามมาตรฐานของ syscall ของ OS ต่าง ๆ อย่าง Windows ก็จะใช้ของ Windows Syscall ของ Linux/UNIX ก็จะเป็น POSIX-like Syscall และที่บอกไม่ถูก 100% คือมันก็มีแปลงโค้ดไปมาบ้างแต่ไม่ได้แปลงหมด อย่างใน PC ปัจจุบันไม่ได้แตะต้อง Address Space ตรง ๆ แล้ว จะมีพวก MMU เข้ามากั้นอีกทีหนึ่ง (และ MMU ของ x86_64 ถือว่าแทบจะซับซ้อนที่สุดแล้วในบรรดาคอมพิวเตอร์ด้วยกัน) ซอฟต์แวร์ที่ทำงานอยู่ต้องอาศัยการติดต่อการจัดสรรพื้นที่ผ่าน kernel เพื่อขอใช้พื้นที่เข้าถึง (Address Space) ตามสมควร (และเป็นเหตุผลว่าทำไมซอฟต์แวร์ DOS เก่า ๆ จึงรันไม่ได้แล้วบนพีซีสถาปัตยกรรมเดียวกัน และก็เหตุผลที่ Windows 95/98 จอฟ้าบ่อยครั้งจากซอฟต์แวร์ยุคเดียวกัน) และกรณีที่ซีพียูมีบั๊กหรือสิ่งที่ต้องแก้ไข ก็จะใช้ microcode เข้าไป update ชุดคำสั่งข้างในอีกที
เพิ่มอีกนิด
สำหรับพวกโอเอส ...
Android รันแอพบน runtime ที่ไม่ยึดกับ hardware มานานแล้ว ตัวแอพจะมาในรูปไบท์โค๊ดแล้วคอมไพล์มาเป็น target platform อีกทีนึง (ไม่ว่าจะคอมไพล์ที่เครื่องหรือคอมไพล์ที่ตัวผู้สร้าง) ดังนั้นจึงสามารถบังคับเปลี่ยนผ่านได้ไม่ยากนัก ยกเว้นกรณีเกมที่เขียนมาเป็น Native ซึ่ง Google สามารถบอกว่า "ถ้ายูไม่คอมไพล์มาเป็น 64bit มา ไอจะเอาแอพยูออก" ได้ ด้วยความที่เกมมันเป็นกระแสมาแล้วก็ไปคนเลยไม่ค่อยมีปัญหามากนัก
iOS แอปเปิ้ลควบคุม 100% ใครไม่คอมไพล์มาตามที่แอปเปิ้ลอยากได้ แอปเปิ้ลก็แบน จบ ...
WoA มีทาร์เก็ตอยู่ไม่กี่ตัว คนใช้ก็ไม่ได้เยอะขนาดนั้น แอปก็รันได้บ้างไม่ได้บ้าง (ฮา) ก็ไปบังคับให้นักพัฒนาคอมไพล์มาให้ดี ๆ หรือไม่ก็เขียนเป็น .Net ไป ไม่ได้กระทบเยอะ
พวกโปรแกรมฝังตัว โปรแกรมควบคุม ฯลฯ เท่าที่รู้คือเขียนมาเพื่อให้รันบนเครื่องนั้น ๆ ดังนั้นก็ต้อง compile ให้ตรงกับเครืองนั้น ๆ อยู่ดี ไม่ว่ามันจะรองรับอะไรบ้างก็ตาม
Server ก็อาจจะใช้ source distribution คอมไพล์โปรแกรมใหม่ทุกครั้งที่ติดตั้ง ฟังดูเหมือนเสียเวลา แต่มันก็คอมไพล์ครั้งเดียวใช้ยาว ๆ ได้ ส่วนพวก closed-source ก็แค่บอกว่า "ไม่รองรับ" จบเลย
ในขณะที่ ARM กำลังชิงความได้เปรียบตรงนี้แถมมีชิป M* ของ Apple มาช่วยดัน ถ้าฝั่ง x86_64 ยังหาทางออกเรื่องนี้ไม่ได้ กลายเป็นต้องอุ้ม 32 bit ไปเรื่อยๆ ในระยะยาว อาจจะกลายเป็นเสียมากกว่าได้
..: เรื่อยไป