Trong công nghệ phần mềm, **porting** là quá trình thích ứng phần mềm với mục đích đạt được một dạng thực thi nào đó trong môi trường điện toán khác (ví dụ: CPU, hệ điều hành hoặc thư viện bên thứ ba khác) với thiết kế ban đầu của một chương trình. Thuật ngữ này cũng được sử dụng khi phần mềm/phần cứng được thay đổi để làm cho chúng có thể sử dụng được trong các môi trường khác nhau.

Phần mềm là có tính di động khi chi phí porting nó vào một nền tảng mới thấp hơn so với chi phí của việc viết nó từ đầu một cách đáng kể.

Từ nguyên
---------

Thuật ngữ "port" bắt nguồn từ từ Latin *portāre*, có nghĩa là "mang theo". Khi mã lệnh không tương thích với một hệ điều hành hoặc kiến ​​trúc cụ thể, mã lệnh phải được "chuyển" sang hệ thống mới.

Thuật ngữ này thường không được áp dụng cho quá trình điều chỉnh phần mềm để chạy với bộ nhớ ít hơn trên cùng một CPU và hệ điều hành, cũng không áp dụng cho việc viết lại mã nguồn bằng một ngôn ngữ khác (tức là chuyển đổi hoặc dịch thuật).

Các nhà phát triển phần mềm thường cho rằng phần mềm mà họ viết là di động, có nghĩa là chỉ cần ít nỗ lực để thích ứng với môi trường mới. Số lượng nỗ lực thực sự cần phụ thuộc vào một số yếu tố, bao gồm mức độ khác nhau môi trường ban đầu (nền tảng nguồn) với môi trường mới (nền tảng mục tiêu), kinh nghiệm của các tác giả gốc khi biết cấu trúc ngôn ngữ lập trình và các lời gọi thư viện bên thứ ba dường như không thể di chuyển được và nỗ lực của các tác giả ban đầu chỉ sử dụng các cấu trúc di động (các cấu trúc nền tảng cụ thể thường cung cấp một giải pháp rẻ hơn).

Lịch sử
-------

Số lượng CPU và hệ điều hành khác nhau đáng kể được sử dụng trên máy tính để bàn hiện nay nhỏ hơn nhiều so với trước đây. Sự thống trị của kiến ​​trúc x86 có nghĩa là hầu hết các phần mềm máy tính để bàn không bao giờ được chuyển đến một CPU khác. Trong cùng một thị trường, sự lựa chọn của các hệ điều hành đã được giảm xuống một cách hiệu quả thành ba: Microsoft Windows, macOS và Linux. Tuy nhiên, trong các hệ thống nhúng và thị trường di động, tính di động vẫn là một vấn đề quan trọng, với ARM là một sự thay thế được sử dụng rộng rãi.

Các tiêu chuẩn quốc tế, như được ban hành bởi ISO, tạo điều kiện thuận lợi cho việc chuyển đổi bằng cách chỉ định các chi tiết của môi trường tính toán theo cách giúp giảm sự khác biệt giữa các nền tảng tuân thủ tiêu chuẩn khác nhau. Viết phần mềm nằm trong giới hạn được chỉ định bởi các tiêu chuẩn này đại diện cho một nỗ lực thực tế mặc dù không tầm thường. Việc port một chương trình như vậy giữa hai nền tảng tuân thủ tiêu chuẩn (giống như POSIX.1) có thể chỉ là vấn đề tải mã nguồn và biên dịch lại nó trên nền tảng mới. Tuy nhiên, thực tế thường thấy rằng các sửa đổi nhỏ khác nhau là bắt buộc, do sự khác biệt nền tảng tinh tế. Hầu hết các tiêu chuẩn bị "vùng xám" nơi khác biệt trong việc giải thích các tiêu chuẩn dẫn đến các biến thể nhỏ từ nền tảng đến nền tảng.

Ngoài ra, còn có một số công cụ hỗ trợ chuyển đổi, chẳng hạn như GNU Compiler Collection, cung cấp các ngôn ngữ lập trình nhất quán trên các nền tảng khác nhau, và Autotools, tự động phát hiện các biến thể nhỏ trong môi trường và điều chỉnh phần mềm tương ứng trước khi biên dịch.

Các trình biên dịch cho một số ngôn ngữ lập trình bậc cao (e.g. Eiffel, Esterel) có được tính di động bằng cách xuất mã nguồn ở một ngôn ngữ trung gian bậc cao khác (giống như C) mà trình biên dịch cho nhiều nền tảng thường có sẵn.

Hai hoạt động liên quan đến (nhưng khác biệt) porting là mô phỏng và biên dịch chéo.

Porting trình biên dịch
-----------------------

Thay vì dịch trực tiếp sang mã máy, các trình biên dịch hiện đại dịch sang một mã trung gian độc lập của máy để tăng cường tính di động của trình biên dịch và giảm thiểu các nỗ lực thiết kế. Ngôn ngữ trung gian định nghĩa một máy ảo có thể thực thi tất cả các chương trình được viết bằng ngôn ngữ trung gian (một máy được định nghĩa bằng ngôn ngữ của nó và ngược lại). Các hướng dẫn mã trung gian được dịch thành các chuỗi mã máy tương đương bằng trình tạo mã để tạo mã thực thi. Nó cũng có thể bỏ qua việc tạo mã máy bằng cách thực sự thực hiện một trình thông dịch hoặc JIT cho máy ảo.

Việc sử dụng mã trung gian tăng cường tính di động của trình biên dịch, vì chỉ có mã phụ thuộc máy (trình thông dịch hoặc trình tạo mã) của trình biên dịch cần được port đến máy đích. Phần còn lại của trình biên dịch có thể được nhập dưới dạng mã trung gian và sau đó được xử lý thêm bởi trình tạo mã hoặc trình thông dịch được mã hóa, do đó tạo phần mềm biên dịch hoặc thực thi trực tiếp mã trung gian trên trình thông dịch. Phần độc lập của máy có thể được phát triển và thử nghiệm trên một máy khác (*host machine*). Điều này làm giảm đáng kể các nỗ lực thiết kế, bởi vì phần máy độc lập cần được phát triển chỉ một lần để tạo mã trung gian di động.

Một trình thông dịch kém phức tạp hơn và do đó dễ dàng port hơn so với trình tạo mã, vì nó không thể thực hiện tối ưu hóa mã do chế độ xem mã chương trình bị giới hạn (nó chỉ thấy một lệnh tại một thời điểm và bạn cần một chuỗi để thực hiện tối ưu hóa). Một số trình thông dịch cực kỳ dễ dàng để port, bởi vì chúng chỉ đưa ra giả định tối thiểu về tập lệnh của phần cứng cơ bản. Kết quả là, máy ảo thậm chí còn đơn giản hơn so với CPU mục tiêu.

Viết các nguồn trình biên dịch hoàn toàn bằng ngôn ngữ lập trình mà trình biên dịch có nghĩa vụ dịch, tạo ra cách tiếp cận sau, tốt hơn được gọi là trình biên dịch bootstrapping, khả thi trên máy đích:

1. Port trình thông dịch. Điều này cần phải được mã hóa trong mã assembly, sử dụng một bộ assembler đã có trên hệ thống đích
2. Điều chỉnh nguồn của trình tạo mã cho máy mới.
3. Thực thi nguồn được điều chỉnh bằng cách sử dụng trình thông dịch với nguồn bộ tạo mã như đầu vào. Điều này sẽ tạo mã máy cho trình tạo mã.

Phần khó khăn của việc viết mã các thói quen tối ưu hóa được thực hiện bằng cách sử dụng ngôn ngữ cấp cao thay vì ngôn ngữ assembly của mục tiêu.

Theo các nhà thiết kế ngôn ngữ BCPL, mã giải thích (trong trường hợp BCPL) nhỏ gọn hơn mã máy; điển hình là từ 2 đến 1. Mã giải thích tuy nhiên chạy chậm hơn khoảng 10 lần so với mã được biên dịch trên cùng một máy.

Các nhà thiết kế ngôn ngữ lập trình Java cố gắng tận dụng lợi thế của sự nhỏ gọn của mã giải nghĩa, bởi vì một chương trình Java có thể cần được truyền qua Internet trước khi thực thi có thể bắt đầu trên Java Virtual Machine đích.

 Port video game
----------------

Porting cũng là thuật ngữ được sử dụng khi video game được thiết kế để chạy trên một nền tảng, có thể là arcade, video game console, hay PC, được chuyển đổi để chạy trên nền tảng khác. Trước đó trò chơi video "port" thường không phải port thật sự, nhưng thay vì phiên bản làm lại của trò chơi. Tuy nhiên, nhiều trò chơi video thế kỷ 21 được phát triển bằng phần mềm (thường trong C++) có thể xuất mã cho một hoặc nhiều consoles cũng như cho PC mà không cần phải port thực tế (thay vì dựa vào việc chuyển đổi chung thư viện thành phần riêng lẻ).

Nhiều port ban đầu bị các vấn đề về chất lượng gameplay đáng kể vì các máy tính khác nhau rất nhiều. Richard Garriott đã tuyên bố vào năm 1984 tại Origins Game Fair rằng Origin Systems đã phát triển trò chơi máy tính cho dòng Apple II trước rồi chuyển chúng sang Commodore 64 và Atari 8-bit, bởi vì các sprites của máy sau này và các tính năng tinh vi khác được port từ chúng sang Apple "khó khăn hơn nhiều, có lẽ thậm chí không thể". Nhận xét phàn nàn về các ports ảnh hưởng từ "Apple conversionitis", giữ lại "âm thanh tệ hại và đồ họa màu đen-trắng-xanh-tím" của Apple; sau tuyên bố của Garriott, khi Dan Bunten hỏi "người dùng Atari và Commodore trong số khán giả, Bạn có hài lòng với cá bài viết của Apple không?" khán giả hét lên "Không!", Garriott trả lời,, "[Nếu không] phiên bản Apple sẽ không bao giờ được thực hiện. Từ quan điểm của nhà xuất bản không phải là tiền khôn ngoan".

Những nhóm làm việc khác. Ozark Softscape, ví dụ, đã viết M.U.L.E. cho Atari đầu tiên bởi vì họ thích phát triển cho các máy tính tiên tiến nhất, loại bỏ hoặc thay đổi các tính năng khi cần thiết trong quá trình chuyển port. Chính sách như vậy không phải lúc nào cũng khả thi; Bunten nói rằng "M.U.L.E. không thể hoàn tất cho Apple",, và rằng các phiên bản phi-Atari của *The Seven Cities of Gold* đều thua kém.

Khi một trò chơi được gọi là "arcade hoàn hảo", điều này có nghĩa là trò chơi đã được chuyển từ phiên bản arcade sang nền tảng khác, chẳng hạn như console hay máy tính, mà không có bất kỳ thay đổi đáng kể nào đối với hoạt động của trò chơi. Điều này có nghĩa là đồ họa, âm thanh và lối chơi, cùng với các đặc điểm khác của trò chơi (bao gồm cả lỗi), là trung thành với phiên bản arcade. Nó là một thuật ngữ chủ yếu được sử dụng bởi các nhà phê bình chuyên nghiệp và đôi khi, nhưng không phải luôn luôn, có nghĩa là trò chơi là 100% giống hệt nhau.Nó thường có nghĩa là sự khác biệt có thể là nhỏ (chẳng hạn như thời gian tải lâu hơn), hoặc đơn giản là bản port có thể duy trì trải nghiệm của trò chơi gốc nhiều nhất.

"(Console) port" là một trò chơi ban đầu được thực hiện cho một console (giống như Wii hay Xbox 360) trước khi một phiên bản giống hệt nhau được tạo ra có thể được chơi trên một máy tính cá nhân hoặc bất kỳ nền tảng console khác. Thuật ngữ này đã được cộng đồng game thủ sử dụng rộng rãi. Quá trình chuyển một game từ console sang PC thường được coi là tiêu cực do mức hiệu suất cao hơn mà các máy tính thường bị tận dụng,một phần do phần cứng console được cố định trong suốt quá trình chạy (với các game đang được phát triển cho các console specs), trong khi máy tính trở nên mạnh mẽ hơn khi phần cứng phát triển, nhưng cũng do các trò chơi được chuyển đôi khi được tối ưu hóa kém cho máy tính cá nhân hay lazily port. Mặc dù có sự khác biệt lớn về mặt kiến ​​trúc, nhưng sự khác biệt về kiến ​​trúc có thể tồn tại như việc sử dụng bộ nhớ hợp nhất trên console.

Xem thêm
--------

* Trình giả lập Console
* Source port
* Đa nền tảng

Ghi chú
-------

1. ↑  D. E. Whitten (1975). "A machine and configuration independent Fortran: Portable Fortran". *IEEE.org*.
2. ↑  "Portability Issues". .. discusses.. portability of.. Fortran
3. ↑  "port, v.2". *Oxford English Dictionary (OED Online)*. Oxford University Press. Truy cập ngày 21 tháng 12 năm 2017. Origin: Of multiple origins. Partly a borrowing from French. Partly a borrowing from Latin. Etymons: French *porter*; Latin *portāre*.... 1. *trans.* To carry, bear, or convey; to bring.
4. ↑  Tanenbaum 1984, Section 1.1 - LANGUAGES,LEVELS, AND VIRTUAL MACHINES, p. 3, describes the terms and their relations.
5. ↑  Tanenbaum 1984, Chapter 1 - INTRODUCTION, p. 2, explains translation and interpretation.
6. ↑  Richards,Whitby-Strevens 1984, Section 7.1 - Introduction, p. 124, explains compiler portability using intermediate code.
7. ↑  Richards,Whitby-Strevens 1984, Section 7.4 - The bootstrapping process and INTCODE, p. 133, explains the role of the INTCODE interpreter.
8. ↑  Richards,Whitby-Strevens 1984, Section 7.4.3 - Example, p. 136, gives an example translation of a BCPL program into INTCODE for the interpreter.
9. 1 2  Bunten, Dan (tháng 12 năm 1984). "Dispatches / Insights From the Strategy Game Design Front". *Computer Gaming World*: 40. Truy cập ngày 31 tháng 10 năm 2013.
10. 1 2  "The CGW Computer Game Conference". *Computer Gaming World* (panel discussion): 30. tháng 10 năm 1984. Truy cập ngày 31 tháng 10 năm 2013.
11. ↑  Dunnington, Benn; Brown, Mark R.; Malcolm, Tom (January–February 1987). "64/128 Gallery". *Info*: 14–21.Quản lý CS1: định dạng ngày tháng (liên kết)
12. ↑  Stanton, Jeffrey; Wells, Robert P.; Rochowansky, Sandra; Mellid, Michael biên tập (1984). *The Addison-Wesley Book of Atari Software*. Addison-Wesley. tr. 12, 21, 44, 126. ISBN 0-201-16454-X.
13. ↑  Bernstein, Harvey (tháng 5 năm 1985). "Beyond Castle Wolfenstein". *Antic*. tr. 83. Truy cập ngày 8 tháng 1 năm 2015.
14. ↑  Bunten, Dan. "The Game Collection". *Ozark Softscape M.U.L.E*. Truy cập ngày 4 tháng 10 năm 2017.

Chú thích
---------

* Martin Richards and Colin Whitby-Strevens (1984): *BCPL, the language and its compiler..*
* Andrew S. Tanenbaum (1984): *Structured computer organization* 10th Print..

| * x
* t
* s
Công nghệ phần mềm |
| --- |
| Các lĩnh vực | Phân tích yêu cầu • Phân tích hệ thống • Thiết kế phần mềm • Lập trình máy tính • Các phương pháp hình thức • Kiểm thử phần mềm • Triển khai phần mềm • Bảo trì phần mềm  |
| Các khái niệm | Mô hình hóa dữ liệu • Kiến trúc doanh nghiệp • Chi tiết hóa chức năng • Ngôn ngữ mô hình hóa • Mô hình lập trình • Phần mềm • Kiến trúc phần mềm • Phương pháp học phát triển phần mềm • Quy trình phát triển phần mềm • Chất lượng phần mềm • Bảo đảm chất lượng phần mềm • Khảo cổ học phần mềm • Phân tích có cấu trúc  |
| Các định hướng | Định hướng khía cạnh • Định hướng đối tượng • Ontology • Định hướng dịch vụ • Vòng đời phát triển hệ thống |
| Các mô hình | 

|  |  |
| --- | --- |
| Các mô hình phát triển | Linh hoạt • Mô hình lặp • RUP • Scrum • Mô hình xoắn ốc • Mô hình thác nước • XP • V-Model • Mô hình tăng tiến • Mô hình nguyên mẫu |
| Các mô hình khác | Automotive SPICE • CMMI • Mô hình dữ liệu • Mô hình hàm • Mô hình thông tin • Mô hình hóa meta • Mô hình đối tượng • Mô hình hệ thống • Mô hình quan sát |
| Các ngôn ngữ mô hình hóa | IDEF • UML |

 |
| Các kỹ sư phần mềm | Kent Beck • Grady Booch • Fred Brooks • Barry Boehm • Ward Cunningham • Ole-Johan Dahl • Tom DeMarco • Martin Fowler • C. A. R. Hoare • Watts Humphrey • Michael A. Jackson • Ivar Jacobson • Craig Larman • James Martin • Bertrand Meyer • David Parnas • Winston W. Royce • Colette Rolland • James Rumbaugh • Niklaus Wirth • Edward Yourdon • Victor Basili |
| Các lĩnh vực liên quan | Khoa học máy tính • Kỹ nghệ máy tính • Kỹ nghệ doanh nghiệp • Lịch sử • Quản lý • Toán học • Quản lý dự án • Quản lý chất lượng • Công thái học phần mềm • Kỹ nghệ hệ thống |