Lợi thế của định dạng endian nhỏ là gì?

140

Bộ xử lý Intel (và có thể một số người khác) sử dụng định dạng endian nhỏ để lưu trữ.

Tôi luôn tự hỏi tại sao ai đó muốn lưu trữ các byte theo thứ tự ngược lại. Định dạng này có bất kỳ lợi thế so với định dạng endian lớn?

— Bánh quy
nguồn

1

6502 là bộ xử lý đường ống đầu tiên (đầu tiên?). Tôi dường như nhớ một số tuyên bố về việc nó là một vấn đề nhỏ đối với một số vấn đề liên quan đến hiệu suất do đường ống dẫn - nhưng tôi không biết bây giờ vấn đề đó có thể là gì. Bất kỳ đề xuất?

— Steve314

1

@ Steve314: Câu trả lời của tôi giải thích cách thức endian nhỏ giúp hiệu năng trong CPU có đường ống: lập trình

— viên.stackexchange.com / q / 95854/27874

3

Little endian, big endian - bạn phải chọn cái này hay cái khác. Giống như lái xe bên trái hoặc bên phải đường.

3

Tôi đề nghị bạn viết một số mã bằng ASM, tốt nhất là cho kiến trúc "trường học cũ" như 6502 hoặc Z80. Bạn sẽ thấy ngay tại sao những thứ này sử dụng ít endian. Các kiến trúc sử dụng endian lớn có các đặc điểm nhất định đối với tập lệnh của chúng làm cho định dạng đó thích hợp hơn thay vào đó. Đó không phải là một quyết định độc đoán!

— Stefan Paul Noack

2

Mỗi hệ thống thứ tự byte có lợi thế của nó. Các máy cuối nhỏ cho phép bạn đọc byte thấp nhất trước mà không cần đọc các máy khác. Bạn có thể kiểm tra xem một số là số lẻ hay số chẵn (bit cuối cùng là 0) rất dễ dàng, điều này thật tuyệt nếu bạn thuộc loại đó. Các hệ thống lớn lưu trữ dữ liệu trong bộ nhớ giống như cách con người chúng ta nghĩ về dữ liệu (từ trái sang phải), giúp việc gỡ lỗi ở mức độ thấp dễ dàng hơn.

— Koray Tugay

198

Dù sao cũng có các đối số, nhưng có một điểm là trong một hệ thống cuối nhỏ, địa chỉ của một giá trị đã cho trong bộ nhớ, được lấy theo chiều rộng 32, 16 hoặc 8 bit, là như nhau.

Nói cách khác, nếu trong bộ nhớ bạn có giá trị hai byte:

0x00f0   16
0x00f1    0

lấy '16' làm giá trị 16 bit (c 'ngắn' trên hầu hết các hệ thống 32 bit) hoặc làm giá trị 8 bit (thường là c 'char') chỉ thay đổi hướng dẫn tìm nạp bạn sử dụng - không phải địa chỉ bạn tìm nạp từ.

Trên một hệ thống lớn, với những điều trên được trình bày là:

0x00f0    0
0x00f1   16

bạn sẽ cần tăng con trỏ và sau đó thực hiện thao tác tìm nạp hẹp hơn trên giá trị mới.

Vì vậy, trong ngắn hạn, 'trên các hệ thống endian nhỏ, dàn diễn viên là không có.'

— chiều
nguồn

3

Tất nhiên, giả sử rằng các byte thứ tự cao mà bạn không đọc có thể bị bỏ qua một cách hợp lý (ví dụ: bạn biết rằng dù sao chúng cũng bằng không).

— Steve314

10

@ Steve314: Nếu tôi ở C phát sóng từ 32 đến 16 bit (ví dụ) trên hệ thống bổ sung 2 - phần lớn các hệ thống - các byte không cần phải bỏ qua. Bất kể giá trị của chúng là gì, tôi có thể bỏ qua chúng và vẫn tuân thủ các kỳ vọng của người lập trình và tiêu chuẩn C.

9

@Stritzinger - chúng ta đang nói về mã lắp ráp / mã máy được tạo bởi trình biên dịch, không thể mang theo được. Mã ngôn ngữ cấp cao hơn để biên dịch là di động - nó chỉ biên dịch cho các hoạt động khác nhau trên các kiến trúc khác nhau (như tất cả các ops làm).

— jimwise

7

Tôi không mua lập luận này, bởi vì trên các kiến trúc lớn về cuối, một con trỏ có thể chỉ đến điểm cuối, thay vì bắt đầu, về bất cứ điều gì mà bạn đang đề cập đến và hơn là bạn có cùng một lợi thế.

— dan_waterworth

4

@dan_waterworth không hoàn toàn - ví dụ, hãy ghi nhớ các quy tắc số học của con trỏ trong C, và điều gì xảy ra khi bạn tăng hoặc giảm các phôi của cùng một con trỏ. Bạn có thể di chuyển sự phức tạp, nhưng bạn không thể loại bỏ nó.

— jimwise

45

Tôi luôn tự hỏi tại sao ai đó muốn lưu trữ các byte theo thứ tự ngược lại.

Big endian và little endian chỉ là "trật tự bình thường" và "trật tự ngược" theo quan điểm của con người, và sau đó chỉ khi tất cả những điều này là đúng ...

Bạn đang đọc các giá trị trên màn hình hoặc trên giấy.
Bạn đặt các địa chỉ bộ nhớ thấp hơn ở bên trái và các địa chỉ cao hơn ở bên phải.
Bạn đang viết bằng hex, với nybble bậc cao ở bên trái hoặc nhị phân, với bit quan trọng nhất ở bên trái.
Bạn đọc từ trái sang phải.

Đó là tất cả các quy ước của con người hoàn toàn không quan trọng đối với CPU. Nếu bạn giữ lại số 1 và số 2, và lật số 3, người cuối cùng có vẻ "hoàn toàn tự nhiên" đối với những người đọc tiếng Ả Rập hoặc tiếng Do Thái, được viết từ phải sang trái.

Và có những quy ước khác của con người khiến cho những người lớn cuối cùng có vẻ không tự nhiên, như ...

Byte "cao hơn" (đáng kể nhất) phải ở địa chỉ bộ nhớ "cao hơn".

Quay lại khi tôi chủ yếu lập trình 68K và PowerPC, tôi đã coi big-end là "đúng" và endian nhỏ là "sai". Nhưng vì tôi đã làm nhiều công việc của ARM và Intel hơn, tôi đã quen với người cuối cùng. Nó thực sự không quan trọng.

— Bob Murphy
nguồn

30

Các con số trên thực tế được viết từ [chữ số có nghĩa nhất] từ trái sang [chữ số có nghĩa ít nhất] phải bằng tiếng Ả Rập và tiếng Do Thái.

— Random832

5

Vậy thì tại sao các bit trong một byte được lưu trữ ở định dạng "big endian"? Tại sao không nhất quán?

— tskuzzy

11

Chúng không - bit 0 theo quy ước là ít quan trọng nhất và bit 7 là quan trọng nhất. Hơn nữa, bạn thường không thể đặt hàng trên các bit trong một byte, vì các bit không có địa chỉ riêng lẻ. Tất nhiên, họ có thể có một trật tự vật lý trong một giao thức truyền thông hoặc phương tiện lưu trữ nhất định, nhưng trừ khi bạn làm việc ở cấp độ giao thức hoặc phần cứng cấp thấp, bạn không cần phải lo lắng về thứ tự này.

— Stewart

3

BlueRaja: chỉ theo quy ước viết trên giấy. Điều này không có gì chung với kiến trúc CPU. Bạn có thể viết byte là 0-7 LSB-MSB thay vì 7-0 MSB-LSB và không có gì thay đổi từ quan điểm thuật toán.

— SF.

2

@SF.: "Đẩy ngắn, bật bất cứ thứ gì nhưng ngắn " sẽ khiến bạn bất ngờ. Ví dụ, ngay cả khi bạn không làm hỏng ngăn xếp bằng cách đẩy byte, bạn sẽ không bao giờ bật hoặc ngược lại ... x86 (32-bit), ví dụ, thực sự thực sự muốn ngăn xếp được căn chỉnh theo từ và đẩy hoặc bật bất cứ thứ gì gây ra con trỏ ngăn xếp không phải là bội số của 4 có thể gây ra vấn đề căn chỉnh. Và ngay cả khi không, các công cụ đã đẩy toàn bộ từ / dword / qword / etc tại một thời điểm - vì vậy byte thấp sẽ vẫn là từ đầu tiên bạn nhận được khi bật.

— cHao

41

OK, đây là lý do như tôi đã giải thích cho tôi: Phép cộng và phép trừ

Khi bạn thêm hoặc trừ các số nhiều byte, bạn phải bắt đầu với byte có ý nghĩa nhỏ nhất. Ví dụ: nếu bạn thêm hai số 16 bit, có thể có một số mang từ byte có ý nghĩa nhỏ nhất đến byte có ý nghĩa nhất, vì vậy bạn phải bắt đầu với byte có ý nghĩa nhỏ nhất để xem có mang hay không. Đây là cùng một lý do mà bạn bắt đầu với chữ số ngoài cùng bên phải khi thực hiện bổ sung thủ công. Bạn không thể bắt đầu từ bên trái.

Hãy xem xét một hệ thống 8 bit lấy byte theo tuần tự từ bộ nhớ. Nếu nó tìm nạp byte có ý nghĩa nhỏ nhất trước tiên , nó có thể bắt đầu thực hiện phép cộng trong khi byte quan trọng nhất đang được tìm nạp từ bộ nhớ. Sự song song này là lý do tại sao hiệu suất tốt hơn trong ít endian trên như hệ thống. Nếu phải đợi cho đến khi cả hai byte được tìm nạp từ bộ nhớ hoặc tìm nạp chúng theo thứ tự ngược lại, sẽ mất nhiều thời gian hơn.

Đây là trên các hệ thống 8 bit cũ. Trên một CPU hiện đại, tôi nghi ngờ thứ tự byte tạo ra bất kỳ sự khác biệt nào và chúng tôi chỉ sử dụng ít endian vì lý do lịch sử.

— Martin Vilcans
nguồn

3

À - vậy đó gần như là lý do tôi sử dụng thứ tự chunk cuối nhỏ cho số nguyên lớn. Tôi nên làm việc đó ra. Mọi người thực sự cần phải làm việc trên mạng bây giờ - bộ não của tôi đang rất cần một số bộ phận thay thế và một số nâng cấp triệt để, tôi không thể chờ đợi mãi được!

— Steve314

2

Một suy nghĩ - 6502 không thực hiện nhiều phép toán 16 bit trong phần cứng - xét cho cùng, đó là bộ xử lý 8 bit. Nhưng nó đã thực hiện việc đánh địa chỉ tương đối, sử dụng các offset được ký 8 bit so với địa chỉ cơ sở 16 bit.

— Steve314

2

Lưu ý rằng ý tưởng này vẫn quan trọng đối với nhiều số học số nguyên chính xác (như đã nói bởi Steve314), nhưng ở cấp độ từ. Bây giờ, hầu hết các hoạt động không bị ảnh hưởng trực tiếp bởi độ bền của bộ xử lý: người ta vẫn có thể lưu trữ từ ít quan trọng nhất trước tiên trên một hệ thống lớn, như được thực hiện bởi GMP. Bộ xử lý endian nhỏ vẫn có lợi thế cho một vài thao tác (ví dụ: một số chuyển đổi chuỗi?) Có thể được thực hiện dễ dàng hơn bằng cách đọc từng byte một lần, vì chỉ trên một hệ thống cuối nhỏ, thứ tự byte của các số đó là chính xác.

— vinc17

bộ xử lý endian nhỏ có lợi thế trong trường hợp băng thông bộ nhớ bị hạn chế, như trong một số bộ xử lý ARM 32 bit có bus bộ nhớ 16 bit hoặc 8088 với bus dữ liệu 8 bit: bộ xử lý chỉ có thể tải nửa thấp và làm thêm / phụ / mul ... với nó trong khi chờ đợi một nửa cao hơn

— phuclv

13

Với bộ xử lý 8 bit, nó chắc chắn hiệu quả hơn, bạn có thể thực hiện thao tác 8 hoặc 16 bit mà không cần mã khác và không cần đệm thêm giá trị.

Nó vẫn tốt hơn cho một số hoạt động bổ sung nếu bạn đang xử lý một byte tại một thời điểm.

Nhưng không có lý do gì mà big-endian tự nhiên hơn - trong tiếng Anh, bạn sử dụng mười ba (endian nhỏ) và hai mươi ba (endian lớn)

— Martin Beckett
nguồn

1

Big-endian thực sự dễ dàng hơn cho con người vì nó không yêu cầu sắp xếp lại các byte. Ví dụ, trên PC, 0x12345678được lưu trữ 78 56 34 12trong khi trên hệ thống BE thì 12 34 56 78(byte 0 ở bên trái, byte 3 ở bên phải). Lưu ý số lượng càng lớn (tính theo bit), yêu cầu trao đổi càng nhiều; một WORD sẽ yêu cầu một trao đổi; một DWORD, hai lượt đi (ba lần hoán đổi tổng cộng); một QWORD ba lần vượt qua (tổng cộng 7), v.v. Đó là, (bits/8)-1hoán đổi. Một tùy chọn khác là đọc cả hai tiến và lùi (đọc từng byte về phía trước, nhưng quét toàn bộ # ngược).

— Synetech

Một trăm mười ba là người trung lưu, hoặc người cuối lớn khác với "mười ba" về cơ bản là một chữ số không thập phân. Khi chúng ta đánh vần các con số, có một số sai lệch nhỏ so với các quy ước cơ sở không đổi mà chúng ta sử dụng cho các chữ số, nhưng một khi bạn loại bỏ các trường hợp đặc biệt đó, phần còn lại là lớn - hàng triệu trước hàng ngàn, hàng nghìn trước hàng trăm, v.v.

— Steve314

@ Synetech- may mắn thay, máy tính không phải quan tâm đến cách con người đọc chúng. Điều đó giống như tuyên bố rằng flash NAND tốt hơn bởi vì '

— Martin Beckett

1

@ Steve314, các từ được đánh vần của các con số không thành vấn đề, đó là cách đọc số là thứ chúng ta sử dụng khi lập trình. Martin, không có máy tính nào không phải quan tâm đến cách con người đọc số, nhưng nếu con người dễ đọc chúng, thì việc lập trình (hoặc các công việc liên quan khác) trở nên dễ dàng hơn và một số sai sót và lỗi có thể được giảm hoặc tránh.

— Synetech

@ steve314 Và trong tiếng Đan Mạch, "95" được phát âm là "nữ halvfems" (năm, cộng với bốn mươi rưỡi tuổi hai mươi).

— Vatine

7

Quy ước ngày của Nhật Bản là "big endian" - yyyy / mm / dd. Điều này rất thuận tiện cho việc sắp xếp các thuật toán, có thể sử dụng một chuỗi so sánh đơn giản với quy tắc ký tự đầu tiên thông thường là quan trọng nhất.

Một cái gì đó tương tự áp dụng cho các số cuối lớn được lưu trữ trong một bản ghi đầu tiên có ý nghĩa nhất. Thứ tự quan trọng của các byte trong các trường khớp với tầm quan trọng của các trường trong bản ghi, vì vậy bạn có thể sử dụng a memcmpđể so sánh các bản ghi, không quan tâm nhiều đến việc bạn có so sánh hai từ khóa dài, bốn từ hoặc tám byte riêng biệt hay không.

Lật thứ tự quan trọng của các trường và bạn có được lợi thế tương tự, nhưng đối với các số ít về cuối hơn là cuối lớn.

Điều này có rất ít ý nghĩa thực tế, tất nhiên. Cho dù nền tảng của bạn là lớn cuối hay cuối nhỏ, bạn có thể đặt hàng các trường bản ghi để khai thác thủ thuật này nếu bạn thực sự cần. Đó chỉ là một nỗi đau nếu bạn cần viết mã di động .

Tôi cũng có thể bao gồm một liên kết đến sự hấp dẫn cổ điển ...

http://tools.ietf.org/rfcmarkup?url=ftp://ftp.rfc-editor.org/in-notes/ien/ien137.txt

BIÊN TẬP

Một suy nghĩ thêm. Tôi đã từng viết một thư viện số nguyên lớn (để xem nếu tôi có thể) và vì thế, các khối rộng 32 bit được lưu trữ theo thứ tự nhỏ, bất kể cách nền tảng sắp xếp các bit trong các khối đó. Lý do là ...

Rất nhiều thuật toán tự nhiên bắt đầu hoạt động ở đầu cuối ít quan trọng nhất và muốn các đầu cuối đó được khớp. Ví dụ, ngoài ra, mang theo propogate với các chữ số ngày càng quan trọng hơn, do đó, có ý nghĩa để bắt đầu ở đầu ít quan trọng nhất.
Tăng hoặc thu hẹp một giá trị chỉ có nghĩa là thêm / xóa các đoạn ở cuối - không cần phải thay đổi khối lên / xuống. Sao chép có thể vẫn cần thiết do phân bổ lại bộ nhớ, nhưng không thường xuyên.

Tất nhiên, điều này không liên quan đến bộ xử lý - cho đến khi CPU được tạo ra với sự hỗ trợ số nguyên lớn về phần cứng, đó hoàn toàn là một thứ trong thư viện.

— Steve314
nguồn

7

Không ai khác đã trả lời TẠI SAO điều này có thể được thực hiện, rất nhiều thứ về hậu quả.

Hãy xem xét một bộ xử lý 8 bit có thể tải một byte từ bộ nhớ trong một chu kỳ xung nhịp nhất định.

Bây giờ, nếu bạn muốn tải một giá trị 16 bit, vào (giả sử) thanh ghi một và chỉ 16 bit mà bạn có - tức là bộ đếm chương trình, thì một cách đơn giản để làm điều đó là:

Tải một byte từ vị trí tìm nạp
dịch chuyển byte đó sang bên trái 8 vị trí
tăng bộ nhớ tìm vị trí bằng 1
tải byte tiếp theo (vào phần thứ tự thấp của thanh ghi)

kết quả: bạn chỉ tăng vị trí tìm nạp, bạn chỉ tải vào phần thứ tự thấp của thanh ghi rộng hơn và bạn chỉ cần có thể dịch chuyển sang trái. (Tất nhiên, dịch chuyển sang phải là hữu ích cho các hoạt động khác vì vậy hoạt động này là một chút của một chương trình bên lề.)

Một hậu quả của điều này là các công cụ 16 bit (byte kép) được lưu trữ theo thứ tự Most..Least. Tức là, địa chỉ nhỏ hơn có byte đáng kể nhất - rất lớn về cuối.

Thay vào đó, nếu bạn cố tải bằng endian nhỏ, bạn sẽ cần tải một byte vào phần dưới của thanh ghi rộng, sau đó tải byte tiếp theo vào khu vực tổ chức, dịch chuyển nó và sau đó đưa nó vào đầu thanh ghi rộng hơn của bạn . Hoặc sử dụng một sự sắp xếp phức tạp hơn của gating để có thể tải có chọn lọc vào byte trên cùng hoặc dưới cùng.

Kết quả của việc cố gắng đi ít endian là bạn cần nhiều silicon hơn (công tắc và cổng) hoặc nhiều thao tác hơn.

Nói cách khác, trong điều kiện nhận được tiếng nổ trở lại trong những ngày xưa, bạn có nhiều tiếng nổ hơn cho hầu hết hiệu suất và diện tích silicon nhỏ nhất.

Những ngày này, những nhận xét và khá nhiều không thích hợp, nhưng những thứ như đường ống dẫn điền có thể vẫn là một chút của một vấn đề lớn.

Khi nói đến việc viết s / w, cuộc sống thường dễ dàng hơn khi sử dụng địa chỉ endian nhỏ.

(Và bộ xử lý về cuối lớn có xu hướng về cuối lớn về trật tự byte và little endian về bit-in-byte. Nhưng một số bộ vi xử lý là lạ và sẽ sử dụng chút về cuối lớn đặt hàng cũng như byte đặt hàng. Này làm cho cuộc sống rất thú vị cho nhà thiết kế h / w thêm các thiết bị ngoại vi được ánh xạ bộ nhớ nhưng không có kết quả nào khác đối với người lập trình.)

— quick_now
nguồn

3

jimwise đã làm một điểm tốt. Có một vấn đề khác, trong endian nhỏ bạn có thể làm như sau:

byte data[4];
int num=0;
for(i=0;i<4;i++)
    num += data[i]<<i*8; 

OR 

num = *(int*)&data; //is interpreted as

mov dword data, num ;or something similar it has been some time

Thẳng thắn hơn cho các lập trình viên không bị ảnh hưởng bởi nhược điểm rõ ràng của các vị trí bị tráo đổi trong bộ nhớ. Cá nhân tôi thấy endian lớn là nghịch đảo của những gì là tự nhiên :). 12 nên được lưu trữ và viết là 21 :)

— Cem Kalyoncu
nguồn

1

Điều này chỉ chứng minh rằng nó hoạt động nhanh hơn / dễ dàng hơn ở bất kỳ định dạng nào có nguồn gốc từ CPU. Nó không nói bất cứ điều gì về việc nó tốt hơn. Điều tương tự cũng xảy ra với endian lớn: for(i=0; i<4; i++) { num += data[i] << (24 - i * 8); }tương ứng với move.l data, numCPU endian lớn.

— Martin Vilcans

@martin: một phép trừ ít hơn là tốt hơn trong cuốn sách của tôi

— Cem Kalyoncu

Nó không thực sự quan trọng vì trình biên dịch sẽ hủy bỏ vòng lặp. Trong mọi trường hợp, nhiều CPU có hướng dẫn hoán đổi byte để xử lý vấn đề này.

— Martin Vilcans

Tôi không đồng ý bcoz về endian lớn, tôi sẽ làm {num << = 8; num | = dữ liệu [i]; } ít nhất điều này không phải tính số lượng dịch chuyển trái bằng cách sử dụng mul

— Hayri Uğur Koltuk

@ali: mã của bạn sẽ thực hiện thao tác chính xác mà tôi đã viết và sẽ không hoạt động trên endian lớn.

— Cem Kalyoncu

1

Tôi luôn tự hỏi tại sao ai đó muốn lưu trữ các byte theo thứ tự ngược lại

Số thập phân được viết lớn về cuối. Nó cũng là cách bạn viết nó bằng tiếng Anh Bạn bắt đầu với chữ số có ý nghĩa nhất và chữ số quan trọng nhất tiếp theo đến ít quan trọng nhất. ví dụ

là một nghìn, hai trăm ba mươi bốn.

Đây là cách endian lớn đôi khi được gọi là trật tự tự nhiên.

Trong endian nhỏ, con số này sẽ là một, hai mươi, ba trăm bốn nghìn.

Tuy nhiên, khi bạn thực hiện số học như cộng hoặc trừ, bạn bắt đầu với kết thúc.

  1234
+ 0567
  ====

Bạn bắt đầu với 4 và 7, viết chữ số thấp nhất và ghi nhớ mang theo. Sau đó, bạn thêm 3 và 6, v.v. Để cộng, trừ hoặc so sánh, việc thực hiện sẽ đơn giản hơn, nếu bạn đã có logic để đọc bộ nhớ theo thứ tự, nếu các số bị đảo ngược.

Để hỗ trợ endian lớn theo cách này, bạn cần logic để đọc bộ nhớ ngược lại hoặc bạn có quy trình RISC chỉ hoạt động trên các thanh ghi. ;)

Rất nhiều thiết kế Intel x86 / Amd x64 là lịch sử.

— Peter Lawrey
nguồn

0

Big-endian rất hữu ích cho một số hoạt động (so sánh "bignums" của lò xo có độ dài octet bằng nhau với tâm trí). Little endian cho người khác (có thể thêm hai "bignums"). Cuối cùng, nó phụ thuộc vào phần cứng CPU đã được thiết lập để làm gì, nó thường là cái này hay cái khác (một số chip MIPS, IIRC, có thể chuyển đổi khi khởi động thành LE hoặc BE).

— Vatine
nguồn

0

Khi chỉ lưu trữ và chuyển với độ dài thay đổi được tham gia, nhưng không có số liệu nào có nhiều giá trị, thì LE thường dễ viết hơn, trong khi BE dễ đọc hơn.

Hãy lấy một chuyển đổi int-to-string (và trở lại) làm ví dụ cụ thể.

int val_int = 841;
char val_str[] = "841";

Khi int được chuyển đổi thành chuỗi, thì chữ số có nghĩa nhỏ nhất sẽ dễ trích xuất hơn chữ số có nghĩa nhất. Tất cả có thể được thực hiện trong một vòng lặp đơn giản với một điều kiện kết thúc đơn giản.

val_int = 841;
// Make sure that val_str is large enough.

i = 0;
do // Write at least one digit to care for val_int == 0
{
    // Constants, can be optimized by compiler.
    val_str[i] = '0' + val_int % 10;
    val_int /= 10;
    i++;
}
while (val_int != 0);

val_str[i] = '\0';
// val_str is now in LE "148"
// i is the length of the result without termination, can be used to reverse it

Bây giờ hãy thử tương tự theo thứ tự BE. Thông thường bạn cần một ước số khác có sức mạnh lớn nhất là 10 cho số cụ thể (ở đây là 100). Trước tiên bạn cần tìm cái này. Nhiều thứ hơn để làm.

Chuyển đổi chuỗi thành int dễ thực hiện hơn trong BE, khi nó được thực hiện dưới dạng thao tác ghi ngược. Viết lưu các chữ số có ý nghĩa nhất cuối cùng, vì vậy nó nên được đọc trước.

val_int = 0;
length = strlen(val_str);

for (i = 0; i < length; i++)
{
    // Again a simple constant that can be optimized.
    val_int = 10*val_int + (val_str[i] - '0');
}

Bây giờ làm tương tự theo thứ tự LE. Một lần nữa, bạn cần một yếu tố bổ sung bắt đầu bằng 1 và được nhân với 10 cho mỗi chữ số.

Vì vậy, tôi thường thích sử dụng BE để lưu trữ, bởi vì một giá trị được viết chính xác một lần, nhưng đọc ít nhất một lần và có thể nhiều lần. Đối với cấu trúc đơn giản hơn, tôi cũng thường đi theo lộ trình để chuyển đổi sang LE và sau đó đảo ngược kết quả, ngay cả khi nó ghi giá trị lần thứ hai.

Một ví dụ khác cho việc lưu trữ BE sẽ là mã hóa UTF-8 và nhiều hơn nữa.

— Đảm bảo
nguồn