TI DSP lập trình - là C đủ nhanh hoặc tôi cần một bộ lắp ráp?

Question

Tôi sẽ viết một số chương trình xử lý hình ảnh cho nền tảng Texas Instruments DaVinci. Có những công cụ thích hợp để lập trình bằng ngôn ngữ C, nhưng tôi tự hỏi liệu nó có thực sự có thể tận dụng tối đa bộ xử lý DSP mà không cần sử dụng ngôn ngữ lắp ráp hay không. Bạn có biết về bất kỳ sự so sánh nào về tốc độ giữa các chương trình được viết bằng C và trong assembler trên nền tảng DSP này không?

Answer 1

Trình biên dịch C (theo như tôi đã thử nghiệm) không tận dụng tối đa kiến ​​trúc.

Nhưng bạn có thể thoát khỏi nó, vì DSP có thể đủ nhanh cho các thao tác bạn cần thực hiện.

Vì vậy, nó đi xuống để kiểm tra và lược tả mã của bạn để xem các bộ phận phải được tăng tốc để hệ thống hoạt động.

Answer 2

Tôi đã sử dụng một số TI DSP khác và C thường tốt. Cách tiếp cận thông thường là bắt đầu bằng cách viết tất cả mọi thứ trong C và sau đó cấu hình mã để xem liệu có cần phải tối ưu hóa bằng tay hay không.

Bạn cũng có thể thực hiện tối ưu hóa trong C, bằng cách điều chỉnh mã C cho đến khi bạn nhận được đầu ra lắp ráp bạn muốn. Điều quan trọng là phải biết DSP hoạt động như thế nào và cách làm việc nhanh hơn hoặc chậm hơn.

Answer 3

Phụ thuộc vào trình biên dịch C và định nghĩa của bạn về "đủ nhanh". Trình biên dịch C tiêu chuẩn thường phải vật lộn để làm cho hiệu quả sử dụng phần cứng DSP đặc biệt, chẳng hạn như:

• ngân hàng bộ nhớ Nhiều có thể được truy cập song song
• kiểu dữ liệu cố định điểm
• Thông tư buffers

Answer 4

Thông thường C là một nơi tốt để bắt đầu. Bạn có thể nhận được khuôn khổ tổng thể và các thuật toán nhanh chóng thoát ra, và viết hầu hết các hệ thống ống nước di chuyển dữ liệu xung quanh giữa toán học thực. Khi đã sẵn sàng và bạn hài lòng rằng cấu trúc dữ liệu của bạn là chính xác, bạn có thể xem xét trong một hồ sơ và tìm ra những thói quen cần phải được ép bằng tay.

Answer 5

Tôi sẽ gắn bó với C cho đến khi tôi biết có một điểm phát sóng có thể hưởng lợi từ mã hóa lắp ráp. This is the "profiling" method I use. Bạn có thể ngạc nhiên rằng có nhiều cách để tăng tốc mã không phải là điểm nóng, mà là các cuộc gọi hàm trung gian có thể bị xóa.

Answer 6

Trình biên dịch TI cho C64x/C64x + DSP trên OMAP3 bao gồm hỗ trợ cho những gì TI gọi là các cuộc gọi hàm "nội tại". Họ không thực sự gọi hàm, họ chỉ là một cách để nói cho trình biên dịch biết opcode lắp ráp nào để sử dụng cho một thao tác có thể không thể diễn tả trực tiếp trong C. Nó đặc biệt hữu ích để tận dụng các mã hóa SIMD trong C64x/C64x + DSP từ C.

Ví dụ có thể là:

A = _add2 (B, C);

Lệnh SIMD này thêm các bit 16 và B cao/thấp cùng nhau và lưu trữ kết quả trong 16 bit thấp/cao của A. Bạn không thể diễn đạt điều này trong C thường xuyên, nhưng bạn có thể làm điều đó với nội tại C opcodes.

Tôi đã sử dụng C nội tại để nhận được rất gần với những gì bạn có thể làm với ngôn ngữ lắp ráp toàn diện (trong vòng 5-10%). Nó đặc biệt hữu ích cho các chức năng video như lọc và bù chuyển động (_dotpsu4!).

Tôi thường biên dịch với chuyển đổi -al và nhìn vào đường ống để thử và xác định đơn vị chức năng nào bị quá tải và sau đó nhìn vào bản chất của tôi để xem liệu tôi có thể cân bằng vòng lặp không (nếu tôi đang sử dụng quá nhiều đơn vị S , Tôi có thể thấy nếu tôi có thể thay đổi opcode để sử dụng một đơn vị M).

Ngoài ra, nó rất hữu ích để nhớ rằng C64x DSP có 64 thanh ghi, vì vậy tải lên các biến địa phương và bao giờ gán đầu ra của một lệnh trở lại vào cùng một biến - nó sẽ ảnh hưởng tiêu cực của trình biên dịch khả năng phân phối đúng cách.

Answer 7

so sánh đơn giản của tốc độ có nghĩa là không có gì. Chắc chắn c nếu thuận tiện hơn so với lắp ráp. Bạn phải đo lường chi phí thời gian của hệ thống của bạn, nếu mã c đáp ứng yêu cầu của bạn cho tốc độ, bạn không cần phải sử dụng assembler. Nếu tốc độ không đủ, bạn có thể cấu hình mã của bạn, tìm ra mã nguồn tốn nhiều thời gian nhất chẳng hạn như mã vòng lặp, sau đó tối ưu hóa nó!