Tại sao có thể khó tạo phiên bản 64 bit của chương trình?

Trong lập trình thời gian ngắn của tôi, việc biên dịch bất kỳ C ++, Java, v.v. của tôi cho máy 32 hoặc 64 bit là rất đơn giản, miễn là tôi có nguồn đầy đủ cho chương trình.

Nhưng rất nhiều phần mềm không được phát hành 64 bit. Khó chịu nhất, vẫn chưa có bản phát hành 64 bit của công cụ Unity.

Điều gì gây khó khăn cho việc biên dịch một số chương trình cho máy 64 bit?

compiler 64-bit 32-bit

— calben
nguồn

bởi vì các lập trình viên ngu ngốc cứ tiếp tục giả địnhsizeof(int)==sizeof(void*)

— ratchet freak

Lý do cao nhất trong môi trường của chúng tôi là sự phụ thuộc vào một số thành phần của bên thứ ba không khả dụng dưới dạng 64 bit. Không biết điều đó có đúng với Unity không, nhưng tôi sẽ không quá ngạc nhiên nếu đó là trường hợp.

— Doc Brown

Họ có thể sử dụng typedef như int32, int64 cho int, float, con trỏ thay vì giả định kích thước của chúng. Mà có thể giải quyết rất nhiều vấn đề. Nhiều vấn đề bắt đầu từ khi chúng ta bắt đầu giả định.

— Kshitij

Trên thực tế, đó là một giả định hoàn toàn hợp lý trên các kiến trúc phẳng. Windows đã cố tình làm sai để tránh phá vỡ các vụ lừa đảo của chính họ.

— Joshua

Tại sao đó sẽ là một giả định hợp lý? Tôi hy vọng sẽ có một phong nha operator*cho int, nhưng con trỏ không cần điều đó. Ngoài ra, hầu hết các môi trường Linux và Unix cũng có int32 bit.

— MSalters

Câu trả lời:

Vấn đề chung là rất dễ mã hóa các giả định không có giấy tờ trong một chương trình và rất khó tìm ra những nơi mà những giả định đó được đưa ra. Các ngôn ngữ cấp cao có xu hướng bảo vệ chúng ta khỏi những lo ngại này, nhưng trong các ngôn ngữ cấp thấp hơn được sử dụng để triển khai các nền tảng và dịch vụ, thật dễ dàng để thực hiện những việc không nhất thiết phải di động trên các kiến trúc:

Giả sử rằng intnó đủ lớn để lưu trữ một con trỏ
Giả sử các thuộc tính của biểu diễn con trỏ, ví dụ, để gắn thẻ con trỏ
Giả sử rằng con trỏ dữ liệu và con trỏ mã có cùng kích thước

Ngoài ra còn có mối quan tâm thực tế của quản lý phát hành. Nếu tôi chỉ tạo một bản dựng x86, nó vẫn sẽ chạy trên x86-64, mặc dù có lẽ chậm hơn do số lượng đăng ký có hạn. Trong khi nếu tôi xây dựng cho cả x86 và x86-64, bây giờ tôi phải kiểm tra cả kiến trúc và xử lý các lỗi chỉ có thể phát sinh trên một kiến trúc, làm tăng chi phí vận chuyển một bản phát hành mới.

— Jon Purdy
nguồn

Lưu ý rằng có thể viết một lỗi chỉ xuất hiện khi tệp nhị phân x86 được chạy trên phiên bản 64 bit của HĐH. Nó chỉ khó hơn ;-)

— Steve Jessop

+1. Tôi muốn thêm phần sau vào điểm "quản lý phát hành": nếu phần mềm của tôi phụ thuộc vào các thành phần của bên thứ ba, ngay cả khi có phiên bản 32 và 64 bit của một thành phần cụ thể, nỗ lực bổ sung để thử nghiệm các bản phát hành mới không nên đánh giá thấp. Vì vậy, quản lý phát hành IMHO phải là điểm đầu tiên trong danh sách đó, không chỉ là một ghi chú bên lề.

— Doc Brown

Bạn có thể giải thích về vấn đề kích thước con trỏ int? Có phải vì trong môi trường 64 bit, không gian bộ nhớ sẽ cao hơn mức int cho phép?

— TankorSmash

@TankorSmash: trên x86 bình thường sizeof(int) == sizeof(void *)(cả hai đều là 32 bit); trên x86_64, việc giữ int32 bit là bình thường (vẫn tương thích với x86 và tránh lãng phí dung lượng trong bộ nhớ), nhưng con trỏ phải là 64 bit (vì không gian địa chỉ ảo tăng lên 2 ^ 64), vì vậy chúng không còn nữa xô vào một inthoặc unsigned int.

— Matteo Italia

Hầu hết các phần mềm sẽ hoạt động giống nhau khi được biên dịch cho cả kiến trúc Intel / AMD 32 và 64 bit. Tuy nhiên, một số phần mềm sẽ không. Ngoài sự lười biếng, hoặc tiếp cận đối tượng lớn hơn, có một số lý do cụ thể tại sao việc biên dịch lại thành 64 bit sẽ không hoạt động.

Phần mềm có thể sử dụng các hoạt động con trỏ không an toàn. Có lẽ một chương trình đặt một con trỏ vào một int, thường là 32 bit cho hầu hết các trình biên dịch C và C ++. Con trỏ là 64 bit trong chương trình 64 bit. Điều đó không làm việc.
Các hoạt động dịch chuyển bit có thể tạo ra các kết quả khác nhau nếu loại số nguyên đang được sử dụng có kích thước khác nhau. Đây có thể là một vấn đề khi sử dụng loại dữ liệu thông thường thay vì typedef tiêu chuẩn, chẳng hạn nhưint32_t
Một kiểu dữ liệu được sử dụng trong một liên minh có thể thay đổi kích thước, thay đổi hành vi của liên minh.
Phần mềm có thể chỉ dựa vào các thư viện chỉ có 32 bit. Nói chung, một chương trình 64 bit sẽ chỉ hoạt động với các thư viện 64 bit do các giả định về ngăn xếp, con trỏ, v.v.

Khó khăn mà bạn hỏi trong câu hỏi của bạn chỉ đơn giản là trong một số cơ sở mã có thể có hàng triệu dòng mã thực hiện các hoạt động không an toàn, đưa ra các giả định không an toàn, có các phím tắt và "tối ưu hóa" thông minh được các nhà phát triển đưa vào. Mã này sẽ không biên dịch trong môi trường 64 bit, hoặc nó sẽ biên dịch nhưng có lỗi show-stopper. Có thể mất một thời gian dài để khắc phục tất cả các vấn đề. Có thể một công ty sẽ sửa chúng theo thời gian cho đến khi có thể phát hành phiên bản 64 bit. Có thể một công ty sẽ phát triển "phiên bản 2" cùng với các bản phát hành bảo trì hiện tại vì việc viết lại hoàn toàn là cần thiết.

Đạo đức của câu chuyện là viết mã sạch và không cố gắng đoán thứ hai trình biên dịch hoặc thêm các tối ưu hóa thông minh không cần thiết, có thể phá vỡ phần mềm và có thể không giúp được gì.

Bài viết này đi sâu vào chi tiết hơn nhiều so với tôi có thể hy vọng đưa vào câu trả lời này: 20 vấn đề về chuyển mã C ++ trên nền tảng 64 bit

— Tulains Córdova
nguồn

Các vấn đề có thể đi xa hơn là chỉ biên dịch; Tôi có một người bạn muscian không thể sử dụng FL Studio 64 bit có sẵn vì họ yêu cầu nhiều VST chỉ có 32 bit; kiến trúc plugin dựa trên liên kết động khác bị ảnh hưởng tương tự.

— StarWeaver

Cảm ơn đã chỉnh sửa: Tôi thường RẤT kén chọn ngữ pháp nhưng mắc một vài lỗi. Và @StarWeaver Tôi nghĩ rằng tôi đã chạm vào điều đó khi tôi nói mã có thể biên dịch nhưng có lỗi. Điều này vẫn quay trở lại quan điểm của tôi về việc viết mã sạch cho bất kỳ ngôn ngữ và nền tảng nào bạn đang nhắm mục tiêu.

"có lỗi show-stopper" Trình dừng chương trình là hiển nhiên và "trong khuôn mặt của bạn" và có thể được xử lý. Những gì tôi nghĩ có lẽ tồi tệ hơn là tất cả các vấn đề tạo ra kết quả không chính xác sẽ không được chú ý trong một thời gian dài.

— Burhan Ali