Tôi đang viết một trình thông dịch nhỏ cho một ngôn ngữ như BASIC đơn giản như một bài tập về vi điều khiển AVR trong C bằng chuỗi công cụ avr-gcc. Tuy nhiên, tôi tự hỏi liệu có bất kỳ công cụ mã nguồn mở nào có thể giúp tôi viết lexer và parser không.
Nếu tôi viết nó để chạy trên hộp Linux của mình, tôi có thể sử dụng flex / bison. Bây giờ tôi đã tự giới hạn mình trong nền tảng 8-bit, tôi phải làm tất cả bằng tay, hay không?
Câu trả lời:
Tôi đã triển khai trình phân tích cú pháp cho một ngôn ngữ lệnh đơn giản được nhắm mục tiêu cho ATmega328p . Con chip này có ROM 32k và RAM chỉ 2k. RAM chắc chắn là hạn chế quan trọng hơn - nếu bạn chưa gắn liền với một con chip cụ thể, hãy chọn một con chip có càng nhiều RAM càng tốt. Điều này sẽ làm cho cuộc sống của bạn dễ dàng hơn nhiều.
Lúc đầu, tôi cân nhắc sử dụng flex / bison. Tôi quyết định từ chối lựa chọn này vì hai lý do chính:
Sau khi từ chối Flex & Bison, tôi đã đi tìm các công cụ máy phát điện khác. Dưới đây là một số mà tôi đã xem xét:
Bạn cũng có thể muốn xem qua so sánh của Wikipedia .
Cuối cùng, tôi đã mã hóa bằng tay cả lexer và parser.
Để phân tích cú pháp, tôi đã sử dụng trình phân tích cú pháp gốc đệ quy. Tôi nghĩ Ira Baxter đã hoàn thành rất tốt chủ đề này, và có rất nhiều hướng dẫn trực tuyến.
Đối với lexer của mình, tôi đã viết các biểu thức chính quy cho tất cả các thiết bị đầu cuối của mình, lập sơ đồ máy trạng thái tương đương và triển khai nó như một hàm khổng lồ bằng cách sử dụng goto's để nhảy giữa các trạng thái. Điều này thật tẻ nhạt, nhưng kết quả làm việc tuyệt vời. Ngoài ra, gotolà một công cụ tuyệt vời để triển khai các máy trạng thái - tất cả các trạng thái của bạn có thể có nhãn rõ ràng ngay bên cạnh mã liên quan, không có lệnh gọi hàm hoặc chi phí biến trạng thái và nó nhanh như bạn có thể nhận được. C thực sự không có một cấu trúc tốt hơn để xây dựng các máy trạng thái tĩnh.
Điều cần suy nghĩ: lexers thực sự chỉ là một chuyên môn của trình phân tích cú pháp. Sự khác biệt lớn nhất là ngữ pháp thông thường thường đủ để phân tích từ vựng, trong khi hầu hết các ngôn ngữ lập trình có (chủ yếu) là ngữ pháp không có ngữ cảnh. Vì vậy, thực sự không có gì ngăn cản bạn triển khai lexer dưới dạng trình phân tích cú pháp gốc đệ quy hoặc sử dụng trình tạo phân tích cú pháp để viết lexer. Nó thường không thuận tiện bằng việc sử dụng một công cụ chuyên dụng hơn.
Nếu bạn muốn một cách dễ dàng để viết mã trình phân tích cú pháp hoặc bạn hạn chế về dung lượng, bạn nên viết mã thủ công trình phân tích cú pháp gốc đệ quy; về cơ bản đây là các trình phân tích cú pháp LL (1). Điều này đặc biệt hiệu quả đối với các ngôn ngữ "đơn giản" như Basic. (Tôi đã làm một vài trong số này vào những năm 70!). Tin tốt là chúng không chứa bất kỳ mã thư viện nào; chỉ những gì bạn viết.
Chúng khá dễ viết mã, nếu bạn đã có ngữ pháp. Đầu tiên, bạn phải loại bỏ các quy tắc đệ quy bên trái (ví dụ: X = XY). Điều này nói chung là khá dễ thực hiện, vì vậy tôi để nó như một bài tập. (Bạn không cần phải làm điều này đối với các quy tắc tạo danh sách; xem thảo luận bên dưới).
Sau đó, nếu bạn có quy tắc BNF của biểu mẫu:
X = A B C ;
tạo một chương trình con cho mỗi mục trong quy tắc (X, A, B, C) trả về một boolean nói rằng "Tôi đã thấy cấu trúc cú pháp tương ứng". Đối với X, mã:
subroutine X()
if ~(A()) return false;
if ~(B()) { error(); return false; }
if ~(C()) { error(); return false; }
// insert semantic action here: generate code, do the work, ....
return true;
end X;
Tương tự cho A, B, C.
Nếu mã thông báo là thiết bị đầu cuối, hãy viết mã kiểm tra luồng đầu vào cho chuỗi ký tự tạo nên thiết bị đầu cuối. Ví dụ: đối với một Số, hãy kiểm tra xem luồng đầu vào có chứa các chữ số hay không và đưa con trỏ luồng đầu vào qua các chữ số. Điều này đặc biệt dễ dàng nếu bạn đang phân tích cú pháp ra khỏi bộ đệm (đối với BASIC, bạn có xu hướng nhận được một dòng tại một thời điểm) bằng cách chỉ cần tiến hoặc không tiến một con trỏ quét bộ đệm. Mã này về cơ bản là phần lexer của trình phân tích cú pháp.
Nếu quy tắc BNF của bạn là đệ quy ... đừng lo lắng. Chỉ cần mã lệnh gọi đệ quy. Điều này xử lý các quy tắc ngữ pháp như:
T = '(' T ')' ;
Điều này có thể được mã hóa là:
subroutine T()
if ~(left_paren()) return false;
if ~(T()) { error(); return false; }
if ~(right_paren()) { error(); return false; }
// insert semantic action here: generate code, do the work, ....
return true;
end T;
Nếu bạn có quy tắc BNF với một quy tắc thay thế:
P = Q | R ;
sau đó mã P với các lựa chọn thay thế:
subroutine P()
if ~(Q())
{if ~(R()) return false;
return true;
}
return true;
end P;
Đôi khi bạn sẽ gặp các quy tắc tạo danh sách. Chúng có xu hướng là đệ quy trái và trường hợp này có thể dễ dàng xử lý. Ý tưởng cơ bản là sử dụng lặp thay vì đệ quy, và điều đó tránh đệ quy vô hạn mà bạn sẽ làm điều này theo cách "hiển nhiên". Thí dụ:
L = A | L A ;
Bạn có thể viết mã này bằng cách sử dụng lặp lại như sau:
subroutine L()
if ~(A()) then return false;
while (A()) do { /* loop */ }
return true;
end L;
Bạn có thể viết mã hàng trăm quy tắc ngữ pháp trong một hoặc hai ngày theo cách này. Có nhiều chi tiết hơn để điền vào, nhưng những điều cơ bản ở đây là quá đủ.
Nếu bạn thực sự eo hẹp về không gian, bạn có thể xây dựng một máy ảo thực hiện những ý tưởng này. Đó là những gì tôi đã làm vào những năm 70, khi 8K từ 16 bit là những gì bạn có thể nhận được.
Nếu bạn không muốn viết mã này bằng tay, bạn có thể tự động hóa nó bằng một siêu trình biên dịch ( Meta II ) về cơ bản tạo ra cùng một thứ. Đây là những điều thú vị về kỹ thuật và thực sự giúp bạn thực hiện điều này, ngay cả đối với những nhà ngữ pháp lớn.
Tháng 8 năm 2014:
Tôi nhận được rất nhiều yêu cầu về "cách tạo AST bằng trình phân tích cú pháp". Để biết thông tin chi tiết về vấn đề này, về cơ bản tạo ra câu trả lời này, hãy xem câu trả lời SO khác của tôi https://stackoverflow.com/a/25106688/120163
Tháng 7 năm 2015:
Có rất nhiều người muốn viết một trình đánh giá biểu thức đơn giản. Bạn có thể làm điều này bằng cách thực hiện những việc tương tự như liên kết "Trình tạo AST" ở trên gợi ý; chỉ cần làm số học thay vì xây dựng các nút cây. Đây là một trình đánh giá biểu thức được thực hiện theo cách này .
GCC có thể biên dịch chéo sang nhiều nền tảng khác nhau, nhưng bạn chạy flex và bison trên nền tảng mà bạn đang chạy trình biên dịch. Họ chỉ lấy ra mã C mà trình biên dịch sau đó xây dựng. Kiểm tra nó để xem tệp thực thi kết quả thực sự lớn như thế nào. Lưu ý rằng chúng có các thư viện thời gian chạy ( libfl.av.v.) mà bạn cũng sẽ phải biên dịch chéo tới mục tiêu của mình.
Hãy thử Boost :: Spirit. Đó là một thư viện chỉ dành cho tiêu đề mà bạn có thể đăng nhập và xây dựng một trình phân tích cú pháp rất nhanh, sạch hoàn toàn bằng C ++. Các toán tử được nạp chồng trong C ++ được sử dụng thay vì một tệp ngữ pháp đặc biệt.
Thay vì phát minh lại bánh xe, hãy xem LUA: www.lua.org . Nó là một ngôn ngữ thông dịch có nghĩa là được nhúng trong phần mềm khác và được sử dụng trên các hệ thống quy mô nhỏ, chẳng hạn như hệ thống nhúng. Cây phân tích cú pháp thủ tục tích hợp sẵn, logic điều khiển, toán học và hỗ trợ biến - không cần phải phát minh lại thứ gì đó mà hàng nghìn người khác đã gỡ lỗi và sử dụng. Và nó có thể mở rộng, nghĩa là bạn có thể thêm vào ngữ pháp bằng cách thêm các hàm C của riêng bạn.