Có một nhược điểm nào trong việc phân bổ một lượng lớn ngăn xếp cho một mảng trong một hệ thống nhúng không?

Tôi thường không có vấn đề gì trong việc quyết định liệu một số dữ liệu phải là toàn cầu, tĩnh hay trên ngăn xếp (Không phân bổ động ở đây, vì vậy không sử dụng heap). Tôi cũng đã đọc một vài Q / A như câu hỏi này nhưng câu hỏi của tôi cụ thể hơn vì nó liên quan đến một lượng dữ liệu khổng lồ, rất lớn so với bộ nhớ hệ thống.

Tôi đang làm việc với một mã hiện có mà tôi cố gắng cải thiện (thiết kế, các vấn đề có thể xảy ra, hiệu suất, v.v.). Mã này chạy trên MCU 8 bit cũ chỉ với 4KB RAM . Trong mã này, tôi phải đối mặt với việc sử dụng một mảng gần 1KB (vâng, 1KB trên hệ thống RAM 4KB ). Mỗi byte của mảng này được sử dụng, đó không phải là câu hỏi. Vấn đề là mảng này là một mảng tĩnh trong tệp nơi nó được khai báo, vì vậy vòng đời của nó giống như chương trình (nghĩa là có thể được coi là vô hạn).

Tuy nhiên, sau khi đọc mã, tôi phát hiện ra rằng mảng này không cần vòng đời vô hạn, nó được xây dựng và xử lý theo cách thủ tục đầy đủ, vì vậy chúng ta chỉ có thể khai báo nó trong hàm mà nó được sử dụng, bằng cách này, nó sẽ nằm trên ngăn xếp và do đó chúng tôi sẽ tiết kiệm được 1KB RAM này.

Bây giờ câu hỏi: Đây sẽ là một ý tưởng tốt? Từ quan điểm thiết kế, nếu nó không cần vòng đời vô hạn / toàn cầu, thì nó thuộc về ngăn xếp. Nhưng này, đó là 1KB trong số 4KB, không có bất kỳ nhược điểm nào trong việc phân bổ 25% RAM như thế này? (có thể là 50% hoặc nhiều hơn của ngăn xếp)

Ai đó có thể chia sẻ một số kinh nghiệm với loại tình huống này, hoặc ai đó nghĩ về bất kỳ lý do hợp lệ nào để không đưa mảng này vào ngăn xếp? Tôi đang tìm kiếm những hạn chế kỹ thuật cũng như nhận xét về thiết kế.

Điều duy nhất tôi có ý thức là tôi phải đảm bảo rằng tôi thực sự có 1KB ngăn xếp miễn phí khi vào chức năng này. Có lẽ đó là tất cả những gì tôi phải quan tâm, có thể không.

Điều duy nhất tôi có ý thức là tôi phải đảm bảo rằng tôi thực sự có 1KB ngăn xếp miễn phí khi vào chức năng này.

Vâng, và đó là một hạn chế mạnh mẽ. Bạn sẽ chắc chắn tĩnh hơn bạn có một không gian lớn như vậy có sẵn trên ngăn xếp. Nếu mã nhỏ, nếu bạn đang sử dụng GCC gần đây để biên dịch mã của mình, hãy xem mã này .

BTW, một số bộ vi xử lý giá rẻ có thể sử dụng khung cuộc gọi "lớn" tốn kém hơn so với cuộc gọi "bình thường" (ví dụ: vì tập lệnh của chúng sẽ ưu tiên bù một byte từ con trỏ ngăn xếp). YMMV.

Ngoài ra, nếu bạn đang mã hóa bằng C và nếu bạn cảm thấy rằng mảng lớn của bạn có thể sử dụng lại không gian của nó cho các mục đích khác, bạn có thể xem xét biến nó thành thành viên công đoàn (với biến toàn cục unionloại). Vâng, đó là khá xấu xí.

Ngoài ra, bạn có thể xem xét mã hóa một số phân bổ heap nguyên thủy phù hợp với ứng dụng của bạn (và nó có thể có API khác với malloc& free....).

Mọi người có xu hướng thận trọng với một ngăn xếp lớn, bởi vì nó phát triển ngược về RAM và ghi đè lên các giá trị của các biến, dẫn đến hành vi không thể giải thích được. Nó thậm chí còn tệ hơn, bởi vì bạn cần biết địa chỉ con trỏ ngăn xếp thấp nhất có thể và trừ kích thước để phân bổ khi vào thói quen.

Đây là tất cả công việc để quản lý bộ nhớ phần cứng (sẽ tạo ra bẫy hoặc lỗi khi xảy ra tràn ngăn xếp) hoặc cho trình biên dịch, do nó có các tính năng cho loại phân tích này.

Nếu không, bạn có thể làm những gì bạn muốn với RAM của bạn.

Như các câu trả lời trước đã chỉ ra, trước tiên tôi cũng khuyên bạn nên để mảng tĩnh nếu nó phù hợp với bộ nhớ. Trong hầu hết các trường hợp, điều quan trọng hơn nhiều là phải có dấu chân bộ nhớ xác định, ngay cả khi điều đó có nghĩa là bạn "lãng phí" bộ nhớ cho các biến không được sử dụng mọi lúc. Đặt các mảng lớn vào ngăn xếp của bạn sẽ quá dễ dàng thổi bay nó và tràn các ngăn xếp có xu hướng gây ra các vấn đề khó tìm và khó tái tạo (nếu bạn không thể sử dụng MMU để bảo vệ ngăn xếp).

Đề xuất chia sẻ khối với một số dữ liệu khác với union là hợp lệ IMO, mặc dù đó cũng có thể là nguồn cho các vấn đề khó tìm, nếu bạn định vị sai các biến trong đó.

Nếu bạn sắp hết bộ nhớ và rất cần tạo các biến có thời gian sống ngắn hơn để chia sẻ nó, trước khi chuyển mảng sang stack, tôi sẽ xem xét thêm phân bổ bộ nhớ động, mặc dù nó có nhược điểm riêng. Trong trường hợp này, nó có thể không phải là một câu trả lời, vì mảng nghe có vẻ khá lớn so với bộ nhớ khả dụng.

Bạn có một tùy chọn khác nếu bạn có một số loại lưu trữ flash. Bạn có thể đánh đổi tốc độ truy cập của ram bằng cách lưu trữ dữ liệu của bạn trong flash và đọc và tìm kiếm ở đó. Bạn sẽ chỉ cần tải một bản ghi tại một thời điểm vào ram. Sẽ phức tạp hơn một chút nếu bạn cần cập nhật hồ sơ. Bạn sẽ cần một cơ chế phân cấp độ mòn. Tôi đã làm điều này trong quá khứ và bao gồm một chỉ mục để tăng tốc truy cập.

Đặc biệt là khi làm việc với các hệ thống nhúng, bạn muốn có nhiều lỗi có thể xảy ra vào thời gian biên dịch và không có gì thất bại trong thời gian chạy (thật tuyệt nếu chúng ta có thể đạt được điều này, mặc dù ...).

Tạo các mảng lớn mà bạn có thể cần trong các trạng thái tùy ý của chương trình được phân bổ tĩnh thực hiện chính xác điều đó - Trình liên kết cuối cùng sẽ cảnh báo bạn "điều này không phù hợp với RAM", trong khi phân bổ ngăn xếp sẽ khiến chương trình của bạn gặp sự cố với ngăn xếp khó gỡ lỗi tràn ra.