BOSS

Nền tảng 8085 của chúng tôi không có hệ điều hành. Kinh nghiệm của tôi với hệ thống MPS của M365 và các cơ chế ngắt của IBM System 7 đã thuyết phục tôi rằng chúng tôi cần một bộ chuyển đổi tác vụ đơn giản cho 8085. Vì vậy, tôi đã hình thành nên BOSS: Basic Operating System and Scheduler[1].

Phần lớn BOSS được viết bằng C. Nó cung cấp khả năng tạo các nhiệm vụ đồng thời. Những nhiệm vụ đó không phải là nhiệm vụ ưu tiên — việc chuyển đổi nhiệm vụ không diễn ra dựa trên các ngắt. Thay vào đó, giống như với hệ thống MPS trên M365, các tác vụ được chuyển đổi dựa trên một cơ chế polling đơn giản. Việc polling diễn ra bất cứ khi nào một nhiệm vụ bị chặn bởi một sự kiện.

Lệnh gọi BOSS để khóa một nhiệm vụ trông như thế này:

block(eventCheckFunction);

Lệnh gọi này đã tạm ngừng tác vụ hiện tại, đặt eventCheckFunction vào danh sách polling và liên kết nó với tác vụ mới bị chặn. Sau đó, nó đợi trong vòng lặp polling, gọi từng hàm trong danh sách polling cho đến khi một trong số chúng trả về true. Tác vụ được liên kết với hàm đó sau đó sẽ được phép chạy.

Nói cách khác, như tôi đã nói trước đây, nó là một công cụ chuyển đổi tác vụ đơn giản.

Phần mềm này đã trở thành cơ sở cho rất nhiều dự án trong những năm sau đó. Một trong những dự án đầu tiên là pCCU.

pCCU

Cuối những năm 1970 và đầu những năm 1980 là thời kỳ hỗn loạn của các công ty điện thoại. Một trong những nguồn gốc của sự hỗn loạn đó là cuộc cách mạng kỹ thuật số.

Trong thế kỷ trước, kết nối giữa văn phòng chuyển mạch trung tâm và điện thoại của khách hàng là một cặp dây đồng. Những sợi dây này được bó lại thành những sợi cáp trải dài trong một mạng lưới khổng lồ khắp vùng nông thôn. Lúc thì chúng được treo trên cột, lúc thì chúng được chôn dưới đất.

Đồng là một kim loại quý, và công ty điện thoại đã có hàng tấn (nghĩa đen của hàng tấn) đồng phủ khắp đất nước. Vốn đầu tư này là rất khổng lồ. Phần lớn số vốn đó có thể được thu hồi bằng cách truyền tải cuộc trò chuyện điện thoại qua các kết nối kỹ thuật số. Một đôi dây đồng có thể thực hiện hàng trăm cuộc hội thoại ở dạng kỹ thuật số.

Để đáp lại, các công ty điện thoại đã bắt tay vào quá trình thay thế thiết bị chuyển mạch trung tâm cũ của họ bằng các thiết bị chuyển mạch kỹ thuật số hiện đại.

Sản phẩm 4-Tel của chúng tôi đã thử nghiệm dây đồng, không phải kết nối kỹ thuật số. Vẫn còn khá nhiều dây đồng trong môi trường kỹ thuật số, nhưng chúng ngắn hơn nhiều so với trước đây và chúng được địa phương hóa gần điện thoại của khách hàng. Tín hiệu sẽ được truyền kỹ thuật số từ văn phòng trung tâm đến điểm phân phối cục bộ, nơi mà nó sẽ được chuyển đổi trở lại thành tín hiệu analog và phân phối tới khách hàng qua dây đồng tiêu chuẩn. Điều này có nghĩa là thiết bị đo lường của chúng tôi cần phải được đặt ở nơi bắt đầu các dây đồng, nhưng thiết bị quay số của chúng tôi cần phải ở văn phòng trung tâm. Vấn đề là tất cả các COLT của chúng tôi đều thể hiện cả tính năng quay số và đo lường trong cùng một thiết bị. (Chúng tôi có thể đã tiết kiệm cho mình một gia tài nếu chúng tôi nhận ra ranh giới kiến ​​trúc rõ ràng đó một vài năm trước đó!)

Do đó, chúng tôi đã hình thành một kiến ​​trúc sản phẩm mới: CCU / CMU (bộ điều khiển COLT và bộ đo lường COLT). CCU sẽ được đặt tại văn phòng chuyển mạch trung tâm và sẽ xử lý việc quay số của các đường dây điện thoại sẽ được kiểm tra. CMU sẽ được đặt tại các điểm phân phối địa phương và sẽ đo các dây đồng dẫn đến điện thoại của khách hàng.

Vấn đề là đối với mỗi CCU, có nhiều CMU. Thông tin về CMU nào sẽ được sử dụng cho mỗi số điện thoại do chính bộ chuyển mạch kỹ thuật số nắm giữ. Do đó CCU đã phải truy vấn bộ chuyển mạch kỹ thuật số để xác định CMU nào cần giao tiếp và điều khiển.

Chúng tôi đã hứa với các công ty điện thoại rằng chúng tôi sẽ làm kiến trúc mới này hoạt động kịp thời cho quá trình chuyển đổi của họ. Chúng tôi biết là chúng phải mất vài tháng, nếu không muốn nói là nhiều năm, vì vậy chúng tôi không cảm thấy vội vã. Chúng tôi cũng biết rằng sẽ mất vài năm nhân lực để phát triển phần cứng và phần mềm CCU / CMU mới này.

Bẫy lịch trình

Theo thời gian, chúng tôi nhận thấy rằng luôn có những vấn đề cấp bách buộc chúng tôi phải trì hoãn việc phát triển kiến ​​trúc CCU/CMU. Chúng tôi cảm thấy an toàn về quyết định này bởi vì các công ty điện thoại khác cũng liên tục trì hoãn việc triển khai các bộ chuyển mạch kỹ thuật số. Khi xem lịch trình của họ, chúng tôi cảm thấy tự tin rằng mình còn nhiều thời gian, vì vậy chúng tôi đã liên tục trì hoãn sự phát triển của mình.

Rồi đến một ngày sếp của tôi gọi tôi vào văn phòng của ông ấy và nói: “Một trong những khách hàng của chúng ta đang triển khai bộ chuyển mạch kỹ thuật số vào tháng tới. Đến lúc đó chúng ta phải có CCU/CMU hoạt động. ”

Tôi đã rất kinh hoàng! Làm thế nào chúng ta có thể đạt được số năm phát triển của con người trong một tháng? Nhưng sếp của tôi đã có một kế hoạch …

Trên thực tế, chúng tôi không cần một kiến ​​trúc CCU/CMU đầy đủ. Công ty điện thoại đang triển khai bộ chuyển mạch kỹ thuật số này rất nhỏ. Họ chỉ có một văn phòng trung tâm và chỉ có hai điểm phân phối tại địa phương. Quan trọng hơn, các điểm phân phối “địa phương” không phải đúng là địa phương. Họ thực ra có các thiết bị chuyển mạch analog cũ bình thường chuyển mạch cho hàng trăm khách hàng. Tốt hơn nữa, những bộ chuyển mạch đó thuộc loại có thể quay số bằng COLT bình thường. Thậm chí tốt hơn nữa, số điện thoại của khách hàng chứa tất cả thông tin cần thiết để quyết định sử dụng điểm phân phối cục bộ nào. Nếu số điện thoại có 5, 6 hoặc 7 ở một vị trí nhất định, nó sẽ chuyển đến điểm phân phối 1; nếu không, nó đã đi đến điểm phân phối 2.

Vì vậy, như sếp của tôi đã giải thích với tôi, chúng tôi thực sự không cần CCU/CMU. Những gì chúng tôi cần là một máy tính đơn giản tại văn phòng trung tâm được kết nối bằng đường dây modem với hai COLT tiêu chuẩn tại các điểm phân phối. SAC sẽ giao tiếp với máy tính của chúng tôi tại văn phòng trung tâm và máy tính đó sẽ giải mã số điện thoại và sau đó chuyển tiếp các lệnh quay số và đo lường tới COLT tại điểm phân phối thích hợp.

Do đó, pCCU đã được sinh ra.

Đây là sản phẩm đầu tiên được viết bằng C và sử dụng BOSS đã được triển khai cho khách hàng. Tôi mất khoảng một tuần để phát triển. Câu chuyện này không có ý nghĩa kiến ​​trúc sâu sắc, nhưng nó tạo nên một lời mở đầu đẹp cho dự án tiếp theo.

DLU/DRU

Vào đầu những năm 1980, một trong những khách hàng của chúng tôi là một công ty điện thoại ở Texas. Họ bao phủ một khu vực địa lý rộng lớn. Trên thực tế, các khu vực đó rộng lớn đến mức mỗi một khu vực dịch vụ cần có nhiều văn phòng khác nhau để điều phối thợ. Những văn phòng đó có những người thợ kiểm tra, những người cần thiết bị đầu cuối vào SAC của chúng tôi.

Bạn có thể nghĩ rằng đây là một vấn đề đơn giản để giải quyết – nhưng hãy nhớ rằng câu chuyện này diễn ra vào đầu những năm 1980. Thiết bị đầu cuối từ xa không phổ biến lắm. Để làm cho vấn đề tồi tệ hơn, phần cứng của SAC cho rằng tất cả các thiết bị đầu cuối đều là cục bộ. Các thiết bị đầu cuối của chúng tôi thực sự nằm trên một bus nối tiếp, tốc độ cao, được phát triển riêng.

Chúng tôi có khả năng truy cập thiết bị đầu cuối từ xa, nhưng nó dựa trên modem và vào đầu những năm 1980, modem thường bị giới hạn ở tốc độ 300 bit mỗi giây. Khách hàng của chúng tôi không hài lòng với tốc độ chậm chạp đó.

Thời đó đã bắt đầu có modem tốc độ cao, nhưng chúng rất đắt và chúng cần phải chạy trên các kết nối cố định “có điều kiện”. Chất lượng kết nối quay số chắc chắn là không đủ tốt.

Khách hàng của chúng tôi yêu cầu một giải pháp. Câu trả lời của chúng tôi là DLU/DRU.

DLU/DRU là viết tắt của “Bộ Hiển Thị Cục Bộ” (Display Local Unit) và “Bộ Hiển Thị Từ Xa” (Display Remote Unit). DLU là một bảng mạch máy tính cắm vào khung máy tính SAC và mô phỏng là một bảng quản lý thiết bị đầu cuối. Tuy nhiên, thay vì điều khiển bus nối tiếp cho các thiết bị đầu cuối cục bộ, nó đã lấy luồng ký tự và ghép nó qua một kết nối modem có điều kiện 9600-bps.

DRU là một hộp được đặt ở vị trí của khách hàng ở xa. Nó kết nối với đầu kia của kết nối 9600-bps và có phần cứng để điều khiển các thiết bị đầu cuối trên bus nối tiếp độc quyền của chúng tôi. Nó phân kênh các ký tự nhận được từ liên kết 9600-bps và gửi chúng đến các thiết bị đầu cuối cục bộ thích hợp.

Thật kỳ lạ, phải không? Chúng tôi đã phải thiết kế một giải pháp mà ngày nay đã phổ biến đến mức chúng tôi thậm chí không bao giờ nghĩ đến nó. Nhưng hồi đó …

Chúng tôi thậm chí đã phải phát minh ra giao thức truyền thông của riêng mình bởi vì, trong những ngày đó, các giao thức truyền thông tiêu chuẩn không phải là dạng phần mềm chia sẻ mã nguồn mở. Quả thực, đây là thời điểm rất lâu trước khi chúng ta có bất kỳ loại kết nối Internet nào.

Kiến trúc

Kiến trúc của hệ thống này rất đơn giản, nhưng có một số điểm kỳ quặc thú vị mà tôi muốn nhấn mạnh. Đầu tiên, cả hai thiết bị này đều sử dụng công nghệ 8085 của chúng tôi và cả hai đều được viết bằng C và sử dụng BOSS. Nhưng đó là những điểm tương đồng duy nhất.

Dự án đó có hai người. Tôi là trưởng dự án, và Mike Carew là cộng sự thân thiết của tôi. Tôi đảm nhận việc thiết kế và viết mã của DLU; Mike đã thực hiện DRU.

Kiến trúc của DLU dựa trên mô hình luồng dữ liệu. Mỗi tác vụ thực hiện một công việc nhỏ và tập trung, sau đó chuyển đầu ra của nó cho tác vụ tiếp theo trong hàng, sử dụng một hàng đợi. Hãy nghĩ về mô hình pipe và bộ lọc trong UNIX. Kiến trúc này rất rắc rối. Một nhiệm vụ có thể cung cấp một hàng đợi mà nhiều tác vụ khác sẽ phục vụ. Các tác vụ khác sẽ cung cấp một hàng đợi mà chỉ một tác vụ sẽ phục vụ.

Hãy nghĩ về một dây chuyền lắp ráp. Mỗi vị trí trên dây chuyền lắp ráp đều có một công việc duy nhất, đơn giản, tập trung cao độ để thực hiện. Sau đó, sản phẩm di chuyển đến vị trí tiếp theo trong hàng. Đôi khi dây chuyền lắp ráp chia thành nhiều dây chuyền. Đôi khi những dòng này hợp nhất lại thành một dòng. Đó là DLU.

DRU của Mike đã sử dụng một sơ đồ hoàn toàn khác. Anh ấy đã tạo một nhiệm vụ cho mỗi thiết bị đầu cuối và chỉ cần thực hiện toàn bộ công việc cho thiết bị đầu cuối đó trong nhiệm vụ đó. Không có hàng đợi. Không có luồng dữ liệu. Chỉ là nhiều nhiệm vụ lớn giống hệt nhau, mỗi tác vụ quản lý thiết bị đầu cuối của riêng mình.

Điều này ngược lại với một dây chuyền lắp ráp. Trong trường hợp này, cũng tương tự như có nhiều chuyên gia xây dựng, mỗi người trong số họ lại xây dựng toàn bộ sản phẩm của mình.

Vào thời điểm đó, tôi nghĩ rằng kiến ​​trúc của tôi là vượt trội. Với Mike thì tất nhiên, nghĩ rằng anh ấy tốt hơn. Chúng tôi đã có nhiều cuộc thảo luận thú vị về điều này. Cuối cùng, tất nhiên, cả hai đều hoạt động khá tốt. Và tôi nhận ra rằng các kiến ​​trúc phần mềm có thể rất khác biệt, nhưng vẫn có hiệu quả như nhau.

VRS

Khi những năm 1980 tiến triển, các công nghệ ngày càng mới hơn đã xuất hiện. Một trong những công nghệ đó là máy tính điều khiển bằng giọng nói.

Một trong những tính năng của hệ thống 4-Tel là khả năng xác định vị trí lỗi trong cáp của người thợ. Thủ tục thực hiện như sau:

• Người kiểm tra, tại văn phòng trung tâm, sẽ sử dụng hệ thống của chúng tôi để xác định khoảng cách gần đúng, tính bằng feet, tới lỗi. Điều này sẽ chính xác trong khoảng 20% ​. Người kiểm tra sẽ cử một thợ sửa chữa cáp đến một điểm truy cập thích hợp gần vị trí đó.

• Khi đến nơi, thợ sửa chữa cáp sẽ gọi cho người kiểm tra và yêu cầu bắt đầu quá trình xác định vị trí lỗi. Người kiểm tra sẽ gọi tính năng định vị lỗi của hệ thống 4-Tel. Hệ thống sẽ bắt đầu đo các đặc tính điện của đường dây bị lỗi đó và sẽ in thông báo trên màn hình yêu cầu thực hiện một số thao tác nhất định, chẳng hạn như mở cáp hoặc đoản mạch cáp.

• Người kiểm tra sẽ cho thợ sửa chữa biết hệ thống muốn vận hành như thế nào nào và người thợ sửa chữa sẽ cho người kiểm tra biết sau khi hành động hoàn tất. Sau đó, người kiểm tra sẽ thông báo cho hệ thống biết rằng hành động đã hoàn thành và hệ thống sẽ tiếp tục kiểm tra.

• Sau hai hoặc ba lần tương tác như vậy, hệ thống sẽ tính toán khoảng cách mới đến lỗi. Sau đó, người thợ cáp sẽ lái xe đến vị trí đó và bắt đầu lại quy trình.

Hãy tưởng tượng điều đó sẽ tốt hơn bao nhiêu nếu những người thợ sửa chữa cáp, đang ở trên cột hoặc đứng ở bệ, có thể tự vận hành hệ thống. Và đó chính xác là những gì công nghệ giọng nói mới cho phép chúng tôi làm. Các thợ sửa cáp có thể gọi trực tiếp vào hệ thống của chúng tôi, điều khiển hệ thống bằng cảm biến âm thanh và lắng nghe kết quả được đọc lại cho họ bằng một giọng nói dễ chịu.

Cái tên

Công ty tôi đã tổ chức một cuộc thi nhỏ để chọn một cái tên cho hệ thống mới. Một trong những cái tên sáng tạo nhất được gợi ý là SAM CARP. Nó có nghĩa là “Still Another Manifestation of Capitalist Avarice Repressing the Proletariat” (Vẫn Còn Một Biểu Hiện Khác Của Sự Bạo Ngược Của Tư Bản Đàn Áp Giai Cấp Vô Sản). Không cần phải nói nhiều, cái tên đó đã không được chọn.

Một cái tên khác là Teradyne Interactive Test System (Hệ thống Kiểm tra Tương tác Teradyne). Cái đó cũng không được chọn.

Vẫn còn một cái tên khác là Service Area Test Access Network (Mạng Truy Cập Kiểm Tra Khu Vực Dịch vụ). Nó cũng không được chọn.

Cuối cùng, cái tên thắng cuộc là VRS: Voice Response System (Hệ Thống Phản Hồi Bằng Giọng Nói).

Kiến trúc

Tôi không làm việc với hệ thống này, nhưng tôi đã nghe về những gì đã xảy ra. Câu chuyện tôi sắp kể với bạn là một câu chuyện truyền miệng, nhưng phần lớn, tôi tin nó là chính xác.

Đó là những ngày đầu tiên của máy vi tính, hệ điều hành UNIX, ngôn ngữ C và cơ sở dữ liệu SQL. Chúng tôi đã quyết tâm sử dụng tất cả những công nghệ đó.

Từ rất nhiều nhà cung cấp cơ sở dữ liệu, cuối cùng chúng tôi đã chọn UNIFY. UNIFY là một hệ thống cơ sở dữ liệu hoạt động với UNIX, hệ thống này hoàn hảo đối với chúng tôi.

UNIFY hỗ trợ một công nghệ mới được gọi là Embedded SQL. Công nghệ này cho phép chúng tôi nhúng các lệnh SQL, dưới dạng chuỗi, ngay vào mã C của chúng tôi. Và vì vậy, chúng tôi đã làm điều đó – ở khắp mọi nơi.

Ý tôi là, nó thật tuyệt khi bạn có thể đưa ngay SQL vào mã của mình, ở bất cứ đâu bạn muốn. Và chúng tôi muốn ở đâu? Mọi nơi! Và do đó, các lệnh SQL đã bị bôi ra khắp phần thân code đó.

Tất nhiên, trong những ngày đó, SQL không phải là một tiêu chuẩn vững chắc. Có rất nhiều cú pháp SQL đặc biệt dành riêng cho từng nhà cung cấp. Vì vậy, các lệnh gọi SQL đặc biệt và các lệnh gọi API UNIFY đặc biệt cũng bị bôi ra trong toàn bộ mã.

Những thứ này hoạt động tuyệt vời! Hệ thống đã thành công. Các thợ sửa chữa đã sử dụng nó, và các công ty điện thoại yêu thích nó. Cuộc sống toàn là những nụ cười hạnh phúc.

Sau đó sản phẩm UNIFY chúng tôi đang sử dụng đã bị hủy bỏ.

Ố. Ồ.

Vì vậy, chúng tôi quyết định chuyển sang SyBase. Hay đó là Ingress gì đó? Tôi không nhớ rõ. Chỉ cần nói rằng, chúng tôi đã phải tìm kiểm qua tất cả code C đó, tìm tất cả các lệnh gọi API đặc biệt và SQL được nhúng và thay thế chúng bằng các chức năng tương ứng của nhà cung cấp mới.

Sau ba tháng nỗ lực, chúng tôi đã bỏ cuộc. Chúng tôi không thể làm cho nó hoạt động. Chúng tôi đã bị gắn kết chặt với UNIFY đến nỗi không còn hy vọng gì về việc tái cấu trúc lại chỗ code này với bất cứ chi phí khả thi nào.

Vì vậy, chúng tôi đã thuê một bên thứ ba để duy trì UNIFY cho chúng tôi, dựa trên hợp đồng bảo trì. Và, tất nhiên, phí bảo trì tăng lên từ năm này qua năm khác.

Kết luận VRS

Đây là một trong những cách mà tôi đã học được rằng cơ sở dữ liệu là chi tiết nên được tách biệt khỏi mục đích nghiệp vụ tổng thể của hệ thống. Đây cũng là một trong những lý do mà tôi không thích gắn kết chặt chẽ với các hệ thống phần mềm của bên thứ ba.

[1] Phần mềm này sau đó được đổi tên thành Bob’s Only Successful Software – Phần mềm thành công duy nhất của Bob.

4-TEL

Vào tháng 10 năm 1976, sau khi bị OMC sa thải, tôi trở lại một bộ phận khác của Teradyne – một bộ phận mà tôi sẽ gắn bó trong 12 năm. Sản phẩm tôi làm có tên là 4-TEL. Mục đích của nó là để kiểm tra mọi đường dây điện thoại trong một khu vực dịch vụ điện thoại vào hàng đêm và đưa ra một báo cáo về tất cả các đường dây cần sửa chữa. Nó cũng cho phép nhân viên kiểm tra điện thoại kiểm tra chi tiết các đường dây điện thoại cụ thể.

Hệ thống này bắt đầu ra đời với kiểu kiến ​​trúc tương tự như hệ thống cắt bằng tia Laser. Nó là một ứng dụng nguyên khối được viết bằng hợp ngữ mà không có bất kỳ ranh giới nào đáng kể. Nhưng vào thời điểm tôi gia nhập công ty, điều đó sắp sửa thay đổi.

Hệ thống được sử dụng bởi những người kiểm tra đặt tại một trung tâm dịch vụ (Service Center – SC). Một trung tâm dịch vụ bao gồm nhiều văn phòng trung tâm (Central Office – CO), mỗi văn phòng có thể xử lý tới 10.000 đường dây điện thoại. Phần cứng đo lường và quay số phải được đặt bên trong CO. Vì vậy, đó là nơi đặt các máy tính M365. Chúng tôi gọi những chiếc máy tính đó là máy kiểm tra đường truyền văn phòng trung tâm (Central Office Line Tester – COLT). Một chiếc M365 khác đã được đặt tại SC; nó được gọi là máy tính vùng dịch vụ (Service Area Computer – SAC). SAC có một số modem mà nó có thể sử dụng để quay số COLT và giao tiếp với tốc độ 300-baud (30-cps).

Lúc đầu, các máy tính COLT làm mọi thứ, bao gồm tất cả các giao tiếp bảng điều khiển, menu và báo cáo. SAC chỉ là một bộ ghép kênh đơn giản lấy đầu ra từ các COLT và đưa nó lên màn hình.

Vấn đề với cách thiết lập này là tốc độ 30-cps thực sự chậm. Những người kiểm tra không thích xem các ký tự xuất hiện rề rề trên màn hình, đặc biệt là vì họ chỉ quan tâm đến một vài bit dữ liệu quan trọng. Ngoài ra, trong những ngày đó, bộ nhớ nhân trong M365 rất đắt tiền và chương trình này thì khá lớn.

Giải pháp được đưa ra là tách phần phần mềm quay số và đo đường khỏi phần phân tích kết quả và in báo cáo. Cái sau sẽ được chuyển vào SAC, và cái trước sẽ ở lại COLTs. Điều này sẽ cho phép COLT trở thành một chiếc máy nhỏ hơn, với ít bộ nhớ hơn nhiều và sẽ tăng tốc đáng kể phản hồi tại thiết bị đầu cuối, vì các báo cáo sẽ được tạo trong SAC.

Kết quả này là một thành công xuất sắc. Cập nhật màn hình rất nhanh (sau khi COLT thích hợp đã được quay số) và bộ nhớ của các COLT đã giảm đi rất nhiều.

Ranh giới rất sạch và được tách biệt rõ ràng. Các gói dữ liệu rất ngắn đã được trao đổi giữa SAC và COLT. Các gói này là một dạng DSL rất đơn giản, đại diện cho các lệnh như “DIAL XXXX” hoặc “MEASURE.”

M365 được nạp từ các cuộn băng từ. Những ổ băng từ đó rất đắt tiền và hoạt động không đáng tin cậy lắm – đặc biệt là trong môi trường công nghiệp của văn phòng trung tâm điện thoại. Ngoài ra, M365 là một chiếc máy đắt tiền so với phần còn lại của các thiết bị điện tử trong COLT. Vì vậy, chúng tôi bắt tay vào một dự án thay thế M365 bằng một máy vi tính dựa trên bộ vi xử lý 8085.

Máy tính mới này bao gồm một bảng mạch để lắp vi xử lý 8085, một bảng mạch RAM chứa 32K RAM và ba bảng mạch ROM chứa 12K bộ nhớ chỉ đọc. Tất cả các bo mạch này đều nằm gọn trong cùng một bộ vỏ với phần cứng đo lường, do đó loại bỏ được lớp vỏ ngoài cồng kềnh đã chứa M365.

Các bảng ROM chứa 12 chip Intel 2708 EPROM (Erasable Programmable Read-Only Memory – Bộ nhớ chỉ đọc lập trình có thể xóa)[1]. Hình A.8 cho một ví dụ về con chip như vậy. Chúng tôi đã nạp những con chip đó bằng phần mềm bằng cách chèn chúng vào các thiết bị đặc biệt gọi là đầu ghi PROM được điều khiển bởi môi trường phát triển của chúng tôi. Những con chip này có thể được xóa bằng cách phơi chúng dưới tia cực tím cường độ cao[2].

Bạn tôi CK và tôi đã dịch chương trình hợp ngữ M365 cho COLT sang hợp ngữ của 8085. Bản dịch này được thực hiện bằng tay và chúng tôi mất khoảng 6 tháng. Kết quả cuối cùng là khoảng 30 nghìn dòng code 8085.

Môi trường phát triển của chúng tôi có 64K RAM và không có ROM, vì vậy chúng tôi có thể nhanh chóng tải xuống các file nhị phân đã biên dịch của mình vào RAM và kiểm tra chúng.

Sau khi chương trình hoạt động, chúng tôi chuyển sang sử dụng EPROM. Chúng tôi đã ghi 30 con chip và lắp chúng vào đúng các khe cắm trong ba bảng ROM. Mỗi con chip đều được dán nhãn để chúng tôi có thể biết con chip nào đã đi vào khe nào.

Chương trình 30K là một chương trình nhị phân duy nhất, dài 30K dòng. Để ghi các chip, chúng tôi chỉ cần chia ảnh nhị phân đó thành 30 phần 1K khác nhau và ghi từng phần vào chip được dán nhãn thích hợp.

Điều này hoạt động rất tốt, và chúng tôi bắt đầu sản xuất hàng loạt phần cứng và triển khai hệ thống trên hiện trường.

Nhưng phần mềm thì mềm[3]. Các chức năng thì cần được thêm vào. Các bug thì cần được sửa chữa. Và khi chương trình cài đặt lớn dần, việc cập nhật phần mềm bằng cách ghi 30 con chip mỗi lần cài đặt, ngoài ra còn phải có người xuống tận nơi để thay thế tất cả 30 con chip này tại tất cả các khu vực đã trở thành một cơn ác mộng.

Điều này dẫn tới có thể xảy ra tất cả các loại vấn đề. Đôi khi các chip sẽ bị dán nhãn sai hoặc nhãn bị rơi ra. Đôi khi kỹ sư dịch vụ hiện trường đã nhầm lẫn thay sai chip. Đôi khi kỹ sư dịch vụ hiện trường vô tình làm gãy chân của một trong các chip mới. Kết quả là các kỹ sư hiện trường đã phải mang theo tất cả 30 con chip bổ sung bên mình.

Tại sao chúng tôi phải thay đổi tất cả 30 con chip? Mỗi khi chúng tôi thêm hoặc xóa code khỏi file thực thi 30K của mình, nó sẽ thay đổi địa chỉ mà mỗi lệnh được nạp. Nó cũng thay đổi địa chỉ của các chương trình con và hàm mà chúng tôi đã gọi. Vì vậy, mọi con chip đều bị ảnh hưởng, bất kể sự thay đổi nhỏ đến mức nào.

Một ngày nọ, sếp của tôi đến gặp tôi và yêu cầu tôi giải quyết vấn đề đó. Ông ấy nói rằng chúng tôi cần một cách để thay đổi đối với firmware mà không cần thay thế tất cả 30 con chip mỗi lần. Chúng tôi cùng nhau suy nghĩ về vấn đề này một lúc, và sau đó khởi hành dự án “Vectorization”. Tôi đã mất ba tháng vì nó.

Ý tưởng này rất đơn giản. Chúng tôi chia chương trình 30K thành 32 file nguồn có thể biên dịch độc lập, mỗi file nhỏ hơn 1K. Ở đầu mỗi file nguồn, chúng tôi cho trình biên dịch biết địa chỉ nào để nạp chương trình kết quả (ví dụ: ORG C400 cho con chip sẽ được đưa vào vị trí C4).

Ngoài ra, ở đầu mỗi file nguồn, chúng tôi đã tạo một cấu trúc dữ liệu đơn giản, có kích thước cố định chứa tất cả địa chỉ của tất cả các chương trình con trên chip đó. Cấu trúc dữ liệu này dài 40 byte, vì vậy nó có thể chứa không quá 20 địa chỉ. Điều này có nghĩa là không con chip nào có thể có nhiều hơn 20 chương trình con.

Tiếp theo, chúng tôi tạo một vùng đặc biệt trong RAM được gọi là vectơ. Nó chứa 32 bảng 40 byte – vừa đủ RAM để chứa các con trỏ ở đầu mỗi chip.

Cuối cùng, chúng tôi đã thay đổi tất cả các lệnh gọi đến các chương trình con trên tất cả các chip thành một lệnh gọi gián tiếp thông qua vectơ RAM thích hợp.

Khi bộ vi xử lý của chúng tôi khởi động, nó sẽ quét từng chip và nạp bảng vectơ ở đầu mỗi con chip vào các vectơ RAM. Sau đó, nó sẽ nhảy tới chương trình chính.

Phương án này hoạt động rất tốt. Giờ đây, khi chúng tôi sửa lỗi hoặc thêm một tính năng, chúng tôi có thể chỉ cần biên dịch lại một hoặc hai chip và chỉ gửi những chip đó cho các kỹ sư dịch vụ hiện trường.

Chúng tôi đã làm cho các chip có thể triển khai độc lập. Chúng tôi đã phát minh ra điều phối đa hình. Chúng tôi đã phát minh ra các đối tượng.

Theo nghĩa đen, đây là một kiến ​​trúc plugin. Chúng tôi đã cắm những con chip đó vào. Cuối cùng, chúng tôi đã thiết kế nó để một tính năng có thể được cài đặt vào sản phẩm của chúng tôi bằng cách cắm con chip có tính năng đó vào một trong những ổ cắm chip đang mở. Quá trình điều khiển danh mục sẽ tự động xuất hiện, và việc gắn nó vào ứng dụng chính sẽ tự động xảy ra.

Tất nhiên, vào thời điểm đó, chúng tôi không biết gì về các nguyên tắc hướng đối tượng và chúng tôi cũng không biết gì về việc tách giao diện người dùng khỏi các quy tắc nghiệp vụ. Nhưng những thứ sơ khai đó đã có và chúng hoạt động rất mạnh mẽ.

Một lợi ích phụ không ngờ của phương pháp này là chúng tôi có thể vá firmware thông qua kết nối quay số. Nếu chúng tôi phát hiện thấy lỗi trong firmware, thì chúng tôi có thể quay số thiết bị của mình và sử dụng chương trình giám sát trên bo mạch để thay đổi vectơ RAM cho chương trình con bị lỗi để trỏ đến một bit RAM trống. Sau đó, chúng tôi sẽ nhập chương trình con đã sửa chữa vào vùng RAM đó, bằng cách nhập nó dưới dạng mã máy số hex.

Đây là một lợi ích tuyệt vời cho hoạt động dịch vụ hiện trường của chúng tôi và cho khách hàng của chúng tôi. Nếu họ gặp sự cố, họ không cần chúng tôi gửi chip mới và lên lịch cho cuộc gọi dịch vụ hiện trường khẩn cấp. Hệ thống đó có thể được vá và một con chip mới có thể được cài đặt vào lần bảo trì định kỳ tiếp theo.

Máy tính vùng dịch vụ

Máy tính vùng dịch vụ 4-TEL (Service Area Computer – SAC) dựa trên máy tính mini M365. Hệ thống này giao tiếp với tất cả các COLT ngoài hiện trường, thông qua modem chuyên dụng hoặc quay số. Nó sẽ ra lệnh cho các COLT đó đo đạc đường dây điện thoại, và nhận lại các kết quả thô, và sau đó sẽ thực hiện một phân tích phức tạp về các kết quả đó để xác định và định vị bất kỳ lỗi nào.

Xác định điều phối

Một trong những nền tảng kinh tế cho hệ thống này là dựa vào việc phân bổ các thợ sửa chữa chính xác. Theo quy tắc của hiệp hội, đội sửa chữa được tách ra thành ba loại: văn phòng trung tâm (CO), cáp và drop (thả). Thợ CO khắc phục các sự cố bên trong văn phòng trung tâm. Thợ cáp khắc phục sự cố cáp kết nối từ CO tới khách hàng. Thợ drop khắc phục các sự cố bên trong cơ sở của khách hàng và các đường kết nối cáp bên ngoài với cơ sở đó (“drop”).

Khi một khách hàng phàn nàn về một vấn đề, thì hệ thống của chúng tôi có thể chẩn đoán vấn đề và xác định loại thợ nào cần được cử đi sửa. Điều này tiết kiệm cho các công ty điện thoại rất nhiều tiền bởi vì việc điều phối không đúng nghĩa là khách hàng bị chậm trễ mà thợ thì lãng phí mất chuyến đi.

Phần code để xác định việc điều phối được thiết kế và viết bởi một ai đó rất thông minh, nhưng khả năng giao tiếp lại hết sức tồi tệ. Quá trình viết phần code này đã được mô tả là “Ba tuần nhìn chằm chằm lên trần nhà và hai ngày code tuôn ra từ mọi lỗ thông của cơ thể anh ta – sau đó anh ta nghỉ việc.”

Không ai hiểu nổi phần code này. Mỗi lần chúng tôi cố gắng thêm một chức năng hoặc để sửa một lỗi, thì chúng tôi lại làm hỏng nó theo cách nào đó. Và bởi vì phần code này là một trong những lợi ích kinh tế chính của hệ thống của chúng tôi, nên mọi lỗi mới đều khiến công ty vô cùng khốn đốn.

Cuối cùng, quản lý của chúng tôi chỉ đơn giản là yêu cầu chúng tôi khóa phần code đó lại và không bao giờ sửa đổi nó. Phần code đó chính thức trở nên cho đóng cứng.

Trải nghiệm này khiến tôi ấn tượng về giá trị của code tốt, tinh gọn.

Kiến trúc

Hệ thống này được viết vào năm 1976 bằng trình biên dịch hợp ngữ M365. Đó là một chương trình đơn, nguyên khối với khoảng 60.000 dòng code. Hệ điều hành này là một bộ chuyển đổi tác vụ tự phát triển dựa trên cơ chế polling. Chúng tôi gọi nó là MPS cho hệ thống đa xử lý. Máy tính M365 không có stack tích hợp, vì vậy các biến của một nhiệm vụ cụ thể được lưu giữ trong một vùng đặc biệt của bộ nhớ và được hoán đổi mỗi khi chuyển đổi ngữ cảnh. Các biến chia sẻ thì được quản lý bằng khóa và semaphore. Các vấn đề về reentrancy và race condition là những vấn đề thường gặp khi đó.

Hệ thống này không có sự tách biệt logic điều khiển thiết bị hoặc logic UI khỏi các quy tắc nghiệp vụ của hệ thống. Ví dụ: mã điều khiển modem có thể được tìm thấy trong phần lớn các quy tắc nghiệp vụ và mãUI. Không hề có nỗ lực nào để tập hợp nó vào một module hoặc một interface trừu tượng. Các modem được điều khiển, ở cấp độ bit, bằng mã nằm rải rác khắp nơi trong hệ thống.

Với UI thiết bị đầu cuối thì cũng giống như vậy. Các thông báo và mã điều khiển định dạng không được tách biệt. Chúng bao phủ rất xa và rộng khắp trong toàn bộ code base 60K dòng này.

Các module modem chúng tôi đang sử dụng được thiết kế để gắn trên bo mạch PC. Chúng tôi đã mua các bộ modem đó từ một bên thứ ba và tích hợp chúng với mạch điện khác vào một bảng phù hợp với bảng mạch chủ tùy chỉnh của chúng tôi. Những bộ modem này rất đắt tiền. Vì vậy, sau một vài năm, chúng tôi quyết định thiết kế modem của riêng mình. Chúng tôi, trong nhóm phần mềm, đã yêu cầu nhà thiết kế phần cứng sử dụng các định dạng bit tương tự để điều khiển modem mới. Chúng tôi giải thích rằng mã điều khiển modem đã bị lan tràn khắp nơi và hệ thống của chúng tôi sẽ phải xử lý cả hai loại modem trong tương lai. Vì vậy, chúng tôi đã cầu xin và tán tỉnh, “Xin hãy làm cho modem mới giống như modem cũ theo quan điểm kiểm soát phần mềm.”

Nhưng khi chúng tôi nhận modem mới, cấu trúc điều khiển lại hoàn toàn khác. Nó không chỉ khác một chút. Nó hoàn toàn, và hoàn toàn khác.

Cảm ơn, kỹ sư phần cứng.

Chúng ta phải làm gì đây? Chúng tôi không chỉ đơn giản là thay thế tất cả các modem cũ bằng các modem mới. Thay vào đó, chúng tôi đã trộn modem cũ và mới trong hệ thống của mình. Phần mềm yêu cầu phải xử lý cả hai loại modem cùng một lúc. Chúng tôi đã tiêu tùng khi bị mã điều khiển modem với các cờ và các trường hợp đặc biệt vây quanh mọi nơi phải không? Phải có tới hàng trăm nơi như vậy!

Cuối cùng, chúng tôi đã chọn một giải pháp thậm chí còn tồi tệ hơn.

Một chương trình con cụ thể đã ghi dữ liệu vào bus giao tiếp nối tiếp được sử dụng để điều khiển tất cả các thiết bị của chúng tôi, bao gồm cả modem của chúng tôi. Chúng tôi đã sửa đổi chương trình con đó để nhận dạng các mẫu bit dành riêng cho modem cũ và chuyển chúng thành các mẫu bit mà modem mới cần.

Điều này không đơn giản. Các lệnh tới modem bao gồm các chuỗi ghi vào các địa chỉ IO khác nhau trên bus nối tiếp. Kiểu hack của chúng tôi phải biên dịch các lệnh này theo trình tự và dịch chúng thành một trình tự khác bằng cách sử dụng các địa chỉ IO, định thời gian và vị trí bit khác nhau.

Chúng tôi đã làm cho nó hoạt động, nhưng đó là vụ hack tồi tệ nhất có thể tưởng tượng được. Chính vì sự thất bại này mà tôi đã học được giá trị của việc tách biệt phần cứng khỏi các quy tắc nghiệp vụ và của các interface trừu tượng.

Cuộc thiết kế lại vĩ đại trên trời

Vào thời điểm những năm 1980, ý tưởng sản xuất máy tính mini của riêng bạn và kiến ​​trúc máy tính của riêng bạn bắt đầu không còn hợp thời. Có rất nhiều máy vi tính trên thị trường, và việc sử dụng chúng thì rẻ hơn và tiêu chuẩn hơn so với việc tiếp tục dựa vào các kiến ​​trúc máy tính tự phát triển từ cuối những năm 1960. Điều đó, cộng với kiến ​​trúc khủng khiếp của phần mềm SAC, đã khiến ban quản lý kỹ thuật của chúng tôi bắt đầu tái cấu trúc toàn bộ hệ thống SAC.

Hệ thống mới sẽ được viết bằng C sử dụng UNIX O/S trên đĩa cứng, chạy trên máy vi tính Intel 8086. Các chuyên gia phần cứng của chúng tôi đã bắt đầu làm việc trên phần cứng của chiếc máy tính mới và một nhóm các lập trình viên được chọn lọc, “Tiger Team,” đã được giao nhiệm vụ viết lại.

Tôi sẽ không làm bạn buồn chán với các chi tiết về thất bại ban đầu. Chỉ cần nói rằng Tiger Team lần đầu tiên đã thất bại hoàn toàn sau khi đốt cháy hai hoặc ba năm nhân lực cho một dự án phần mềm không bao giờ mang lại điều gì.

Một hoặc hai năm sau, có thể là năm 1982, quá trình này lại được bắt đầu lại. Mục tiêu là thiết kế lại toàn bộ và hoàn chỉnh SAC bằng C và UNIX trên phần cứng 80286 được thiết kế mới, ấn tượng, mạnh mẽ của chúng tôi. Chúng tôi gọi chiếc máy tính đó là “Deep Thought”.

Phải mất nhiều năm, sau đó nhiều năm, và thậm chí nhiều năm nữa. Tôi không biết khi nào SAC dựa trên UNIX cuối cùng mới được triển khai; tôi nhớ rằng tôi đã rời công ty vào thời điểm đó (1988). Quả thực là tôi không chắc nó đã từng được triển khai hay chưa.

Tại sao lại chậm trễ như vậy? Nói ngắn gọn, đội ngũ thiết kế lại sẽ rất khó bắt kịp với đội ngũ lập trình viên đông đảo đang tích cực bảo trì hệ thống cũ. Đây chỉ là một ví dụ về những khó khăn mà họ gặp phải.

Châu Âu

Cùng thời điểm SAC được thiết kế lại bằng ngôn ngữ C, công ty cũng bắt đầu mở rộng bán hàng sang châu Âu. Họ không thể đợi phần mềm được thiết kế lại hoàn thiện, nên dĩ nhiên, họ đã triển khai các hệ thống M365 cũ vào châu Âu.

Vấn đề là hệ thống điện thoại ở châu Âu rất khác với hệ thống điện thoại ở Hoa Kỳ. Việc tổ chức thủ công và các bộ máy hành chính cũng khác nhau. Vì vậy, một trong những lập trình viên giỏi nhất của chúng tôi đã được cử sang Anh Quốc để lãnh đạo một nhóm các lập trình viên của Anh Quốc nhằm sửa đổi phần mềm SAC để giải quyết tất cả các vấn đề châu Âu này.

Tất nhiên, không có nỗ lực nghiêm túc nào được thực hiện để tích hợp những thay đổi này vào phần mềm của Hoa Kỳ. Điều này đã xảy ra rất lâu trước khi hệ thống mạng internet giúp cho việc truyền các code base lớn qua đại dương trở nên khả thi. Các lập trình viên Anh Quốc này chỉ cần dựa trên code của Hoa Kỳ và sửa đổi nó nếu cần.

Điều này tất nhiên gây ra khó khăn. Các lỗi được tìm thấy ở cả hai bên bờ Đại Tây Dương cần được sửa chữa ở phía bên kia. Nhưng các module đã thay đổi đáng kể, vì vậy rất khó xác định liệu bản sửa lỗi được thực hiện tại Hoa Kỳ có hoạt động ở Anh Quốc hay không.

Sau một vài năm không đâu vào đâu, một đường dây tốc độ cao kết nối các văn phòng giữa Hoa Kỳ và Anh Quốc được lắp đặt, một nỗ lực nghiêm túc đã được thực hiện để tích hợp hai code base này lại với nhau, làm cho sự khác biệt trở thành vấn đề về cấu hình. Nỗ lực này đã thất bại trong lần thử đầu tiên, lần thứ hai và lần thứ ba. Hai code base này, mặc dù rất giống nhau, vẫn còn quá nhiều điểm khác biệt để có thể tái tích hợp – đặc biệt là trong môi trường thị trường thay đổi nhanh chóng vào thời điểm đó.

Trong khi đó, “Tiger Team” vẫn đang cố gắng viết lại mọi thứ trong C và UNIX, nhận ra rằng họ cũng phải xử lý với cả sự khác nhau giữa Châu Âu / Hoa Kỳ này. Và tất nhiên, tiến độ của họ không thể nào mà đẩy nhanh lên được.

Kết luận SAC

Tôi có thể kể cho bạn nghe nhiều câu chuyện khác về hệ thống này, nhưng tôi quá nản để tiếp tục. Chỉ cần nói rằng nhiều bài học khó khăn trong cuộc đời làm phần mềm của tôi đã học được khi tôi đã chìm trong đống mã hợp ngữ khủng khiếp của SAC.

Ngôn ngữ C

Phần cứng máy tính 8085 mà chúng tôi sử dụng trong dự án 4-Tel Micro đã mang lại cho chúng tôi một nền tảng máy tính chi phí tương đối thấp có thể sử dụng cho nhiều dự án khác nhau được nhúng vào môi trường công nghiệp. Chúng tôi có thể nạp nó với 32K RAM và 32K ROM khác, và chúng tôi có một cỗ máy cực kỳ linh hoạt và mạnh mẽ để điều khiển các thiết bị ngoại vi. Những gì chúng tôi không có là một ngôn ngữ linh hoạt và thuận tiện để lập trình cỗ máy này. Trình biên dịch hợp ngữ 8085 chỉ đơn giản là không hề thú vị khi viết mã.

Trên hết, trình biên dịch hợp ngữ mà chúng tôi đang sử dụng được viết bởi các lập trình viên của chính chúng tôi. Nó chạy trên máy tính M365 của chúng tôi, sử dụng hệ điều hành băng từ như được mô tả trong phần “Cắt Laser”.

Như định mệnh đã xảy ra, kỹ sư phần cứng hàng đầu của chúng tôi đã thuyết phục CEO của chúng tôi rằng chúng tôi cần một chiếc máy tính thực sự. Anh ấy thực sự không biết mình sẽ làm gì với nó, nhưng anh ấy có rất nhiều ảnh hưởng chính trị. Vì vậy, chúng tôi đã được mua một chiếc PDP-11/60.

Tôi, một lập trình viên tầm thường vào thời điểm đó, đã rất ngạc nhiên. Tôi biết chính xác những gì tôi muốn làm với chiếc máy tính đó. Tôi đã xác định rằng đây sẽ là máy của tôi.

Khi sách hướng dẫn đến tay, nhiều tháng trước khi giao máy, tôi đã mang chúng về nhà và ngấu nghiến nó. Vào thời điểm máy tính được giao, tôi đã biết cách vận hành cả phần cứng và phần mềm ở mức độ quen thuộc – ít nhất là quen thuộc như việc học ở nhà có thể làm được.

Tôi đã giúp viết đơn đặt hàng. Đặc biệt, tôi đã chỉ định dung lượng lưu trữ đĩa mà máy tính mới sẽ có. Tôi quyết định chúng tôi nên mua hai ổ đĩa có thể tháo rời, mỗi chiếc 25 megabyte[4].

Năm mươi megabyte! Số này dường như là vô hạn rồi! Tôi nhớ khi đi bộ ngang qua các hành lang của văn phòng, vào đêm khuya, miệng lẩm nhẩm như mụ Phù Thủy Xấu Xa của Miền Tây (Wicked Witch of the West): “Năm mươi megabyte! Hahahahahahahahahah! ”

Tôi đã yêu cầu người quản lý cơ sở xây dựng một căn phòng nhỏ để chứa sáu thiết bị đầu cuối VT100. Tôi trang trí nó bằng những bức tranh về không gian. Các lập trình viên phần mềm của chúng tôi sẽ sử dụng căn phòng này để viết và biên dịch mã.

Khi chiếc máy đó đến nơi, tôi đã mất vài ngày để thiết lập nó, nối dây tất cả các thiết bị đầu cuối và đưa mọi thứ vào hoạt động. Đó là một niềm vui – một tình yêu lao động.

Chúng tôi đã mua các trình biên dịch hợp ngữ tiêu chuẩn cho 8085 từ Boston Systems Office và chúng tôi đã dịch mã 4-Tel Micro sang cú pháp đó. Chúng tôi đã xây dựng một hệ thống biên dịch chéo cho phép chúng tôi nạp các file nhị phân đã biên dịch từ PDP-11 xuống môi trường phát triển 8085 và trình ghi ROM của chúng tôi. Và tất cả đều hoạt động muột mà.

C

Nhưng chúng tôi vẫn gặp vấn đề về việc sử dụng trình biên dịch hợp ngữ 8085. Đó không phải là thứ khiến tôi hài lòng. Tôi đã nghe nói rằng có ngôn ngữ “mới” được sử dụng nhiều tại Bell Labs. Họ gọi nó là “C.” Vì vậy, tôi đã mua một bản sao Ngôn ngữ lập trình C của Kernighan và Ritchie. Giống như các hướng dẫn sử dụng PDP-11 vài tháng trước, tôi đã đọc ngấu nghiến cuốn sách.

Tôi đã rất ngạc nhiên bởi sự thanh lịch đơn giản của ngôn ngữ này. Nó không hy sinh sức mạnh của hợp ngữ, mà vẫn cung cấp quyền truy cập vào sức mạnh đó với một cú pháp thuận tiện hơn nhiều. Tôi đã bị thuyết phục.

Tôi đã mua một trình biên dịch C từ Whitesmiths và để nó chạy trên PDP-11. Đầu ra của trình biên dịch là cú pháp trình hợp dịch tương thích với trình biên dịch Boston Systems Office 8085. Như vậy, chúng tôi đã có một con đường để đi từ C đến phần cứng 8085!

Bây giờ vấn đề duy nhất là thuyết phục một nhóm lập trình viên hợp ngữ nhúng rằng họ nên sử dụng C. Nhưng đó là một câu chuyện ác mộng cho một khoảng thời gian khác …

[1] Vâng, tôi hiểu đó là oxymoron.

[2] Chúng có một cửa sổ bằng nhựa trong suốt nhỏ cho phép bạn nhìn thấy chip silicon bên trong và cho phép tia cực tím xóa dữ liệu.

[3] Có, tôi biết rằng khi phần mềm được ghi vào ROM, nó được gọi là firmware — nhưng thậm chí firmware thực sự vẫn mềm.

[4] RKO7