포팅

Porting

소프트웨어 엔지니어링에서 포팅은 주어진 프로그램(예: 다른 CPU, 운영 체제 또는 제3자 라이브러리)이 원래 설계되었던 것과 다른 컴퓨팅 환경에서 어떤 형태의 실행을 달성하기 위한 목적으로 소프트웨어를 적응시키는 과정이다.소프트웨어/하드웨어를 다른 환경에서 사용할 수 있도록 변경하는 경우에도 이 용어가 사용된다.[1][2]

소프트웨어는 새로운 플랫폼에 포팅하는 비용이 처음부터 그것을 쓰는 비용보다 현저히 낮을 때 휴대할 수 있다.소프트웨어 포팅 비용이 구현비용에 비해 낮을수록 휴대성이 뛰어나다고 한다.

어원

"항구"라는 용어는 라틴어 포르테레에서 유래되었는데, 이는 " 운반할 것"[3]이라는 뜻이다.코드가 특정 운영 체제아키텍처와 호환되지 않을 경우, 코드는 반드시 새로운 시스템에 "운반"되어야 한다.

이 용어는 동일한 CPU와 운영 체제에서 적은 메모리로 실행되도록 소프트웨어를 적응시키는 과정에도 일반적으로 적용되지 않으며, 다른 언어로 소스 코드를 다시 쓰는 것(즉, 언어 변환이나 번역)에도 적용되지 않는다.

소프트웨어 개발자들은 종종 자신이 쓰는 소프트웨어가 휴대성이 있다고 주장하는데, 이는 새로운 환경에 적응하기 위한 노력이 거의 필요하지 않다는 것을 의미한다.실제 필요한 노력의 양은 원래의 환경(소스 플랫폼)이 새로운 환경(대상 플랫폼)과 얼마나 다른지, 어떤 프로그래밍 언어 구성과 제3자 라이브러리 호출이 휴대할 가능성이 낮은지를 아는 원저자의 경험 등 몇 가지 요인에 따라 달라진다.원래 저자가 휴대용 구조(플랫폼별 구조는 종종 더 저렴한 솔루션을 제공한다)만을 사용하는 데 투자한 노력의 양.

역사

오늘날 데스크탑에서 사용되는 상당히 다른 CPU와 운영 체제의 수는 과거에 비해 훨씬 적다.x86 아키텍처의 우위는 대부분의 데스크탑 소프트웨어가 결코 다른 CPU에 포팅되지 않는다는 것을 의미한다.같은 시장에서 운영 체제의 선택은 사실상 다음 3가지로 축소되었다.Microsoft Windows, MacOSLinux.그러나 임베디드 시스템모바일 시장에서는 휴대성이 중요한 문제로 남아 있으며, ARM은 널리 사용되는 대안이다.

ISO에 의해 공포된 것과 같은 국제 표준은 서로 다른 표준 준수 플랫폼 간의 차이를 줄이는 데 도움이 되는 방법으로 컴퓨팅 환경의 세부 사항을 명시함으로써 포팅을 크게 촉진한다.이 표준에서 지정한 범위 내에 머무르는 쓰기 소프트웨어는 실용적이긴 하지만 비독점적인 노력을 나타낸다.이러한 프로그램을 두 표준 호환 플랫폼(POSIX.1과 같은) 사이에 포팅하는 것은 소스 코드를 로드하고 새 플랫폼에 다시 컴파일하는 문제일 수 있다.그러나, 실무자들은 종종 플랫폼의 미묘한 차이 때문에 다양한 사소한 수정이 필요하다는 것을 알게 된다.대부분의 표준은 표준 해석의 차이가 플랫폼마다 작은 차이로 이어지는 "회색 영역"에 시달린다.

서로 다른 플랫폼에서 일관된 프로그래밍 언어를 제공하는 GNU 컴파일러 컬렉션, 환경의 사소한 변화 탐지를 자동화하고 컴파일 전에 그에 따라 소프트웨어를 적응시키는 오토툴스 등 포팅을 용이하게 하기 위한 툴도 끊임없이 증가하고 있다.

일부 고급 프로그래밍 언어(예: 에펠, 에스테렐)의 컴파일러는 많은 플랫폼의 컴파일러가 일반적으로 사용 가능한 다른 고급 중간 언어(: C)로 소스 코드를 출력하여 휴대성을 얻는다.

포팅과 관련된 두 가지 활동은 에뮬레이션과 교차 컴파일이다.

포팅 컴파일러

현대 컴파일러는 기계 코드로 직접 번역하는 대신 컴파일러의 휴대성을 높이고 설계 노력을 최소화하기 위해 기계 독립적인 중간 코드로 변환한다.중간 언어는 중간 언어로 작성된 모든 프로그램을 실행할 수 있는 가상 머신을 정의한다(머신은 그 언어로 정의되며 그 반대로 정의된다).[4]중간 코드 명령은 코드 생성기에 의해 동등한 시스템 코드 시퀀스로 변환되어 실행 가능한 코드를 만든다.가상 머신에 대한 통역이나 JIT를 실제로 구현함으로써 머신 코드의 생성을 건너뛸 수도 있다.[5]

중간 코드를 사용하면 컴파일러 자체의 기계 종속 코드(통역기 또는 코드 생성기)만 대상 기계에 포팅하면 되기 때문에 컴파일러의 휴대성이 향상된다.컴파일러의 나머지 부분은 중간 코드로 가져온 다음 포팅된 코드 생성기 또는 통역기에 의해 추가로 처리하여 컴파일러 소프트웨어를 생산하거나 통역기에서 중간 코드를 직접 실행할 수 있다.기계 독립적인 부분은 다른 기계(호스트 머신)에서 개발 및 테스트할 수 있다.이렇게 하면 기계 독립부품을 한 번만 개발하면 휴대용 중간코드를 만들 수 있기 때문에 설계 노력이 크게 줄어든다.[6]

프로그램 코드의 제한된 보기 때문에 코드 최적화를 수행할 수 없기 때문에(한 번에 하나의 명령만 볼 수 있고 최적화하려면 시퀀스가 필요하므로, 통역기는 코드 생성기보다 덜 복잡하고 포팅이 쉽다.일부 통역사는 기본 하드웨어의 명령 집합에 대해 최소한의 가정만 하기 때문에 포팅이 매우 쉽다.결과적으로 가상 시스템은 대상 CPU보다 훨씬 간단하다.[7]

컴파일러 소스를 컴파일러가 번역해야 하는 프로그래밍 언어로 완전히 작성하면 컴파일러 부트스트래핑으로 더 잘 알려진 다음과 같은 접근 방식이 대상 시스템에서 실현 가능하다.

  1. 통역관을 좌현으로 이동시킨다.이 코드는 대상에 이미 존재하는 조립자를 사용하여 조립 코드로 코딩해야 한다.
  2. 코드 생성기의 소스를 새 시스템에 맞게 조정하십시오.
  3. 코드 생성기 소스가 입력된 상태에서 인터프리터를 사용하여 조정된 소스를 실행하십시오.이렇게 하면 코드 생성기의 기계 코드가 생성된다.

최적화 루틴을 코딩할 때 어려운 부분은 대상의 조립 언어 대신 높은 수준의 언어를 사용하여 이루어진다.

BCPL 언어의 설계자에 따르면 (BCPL의 경우) 해석된 코드는 기계 코드보다 더 컴팩트하며, 일반적으로 2 대 1의 비율이다.그러나 해석된 코드는 동일한 시스템에서 컴파일된 코드보다 약 10배 느리게 실행된다.[8]

Java 프로그래밍 언어의 설계자들은 대상의 Java Virtual Machine에서 실행을 시작하기 전에 Java 프로그램이 인터넷을 통해 전송되어야 할 수 있기 때문에 해석된 코드의 압축성을 이용하려고 한다.

비디오 게임 포팅

포팅(Porting)은 아케이드, 비디오 게임기, 개인용 컴퓨터 등 하나의 플랫폼에서 실행하도록 설계된 비디오 게임을 다른 플랫폼에서 실행하도록 변환할 때 사용하는 용어로서, 아마도 약간의 사소한 차이점이 있을 것이다.[9]비디오 게임의 시작부터 1990년대까지, 종종 "전환"으로 알려진 "포트"는 종종 진정한 포트가 아니라, 다른 시스템의 한계로 인해 게임의 버전을 재작업한 경우가 많았다.예를 들어, 1982년 게임인 호빗은 그래픽 이미지로 강화된 텍스트 모험으로, 포트가 개발되었던 개인용 컴퓨터의 범위에 걸쳐 상당히 다른 그래픽 스타일을 가지고 있다.[10]그러나 많은 21세기 비디오 게임은 실제 포팅(대신 개별 컴포넌트 라이브러리의 공통 포팅에 의존하는 것) 없이 PC뿐만 아니라 하나 이상의 콘솔에 대한 코드를 출력할 수 있는 소프트웨어(종종 C++)를 사용하여 개발된다.[10]

아케이드 게임을 하드웨어가 열등한 홈 시스템에 포팅하는 것은 어려웠다.포트로 제작된 아타리 2600용 팩맨 버전은 ROM 공간 부족을 보완하기 위해 원래 게임의 시각적 특징을 많이 생략했고 화면에 여러 귀신이 나타나면서 하드웨어가 고군분투하며 깜빡이는 효과를 냈다.아타리 2600 팩맨의 부진한 성적은 1983년 비디오게임 추락의 원인으로 일부 학자들에 의해 인용되고 있다.[11]

많은 초기 항구들은 컴퓨터가 크게 다르기 때문에 중요한 게임 플레이 품질 문제를 겪었다.[12]리차드 개리어트는 1984년 오리진 게임 박람회에서 오리진 시스템즈가 애플 II 시리즈용 컴퓨터 게임을 먼저 개발한 후 코모도어 64와 아타리 8비트에 포팅했다고 밝혔다. 왜냐하면 후자 머신의 스프라이트와 기타 정교한 특징들이 애플에서 포팅하는 것을 "아마도 훨씬 더 어렵거나 더 불가능할 것"[13]으로 만들었기 때문이다.평론가들은 "애플 변환염"[14]으로 고통 받는 항구들에 대해 불평했다.[15][16] 개리엇의 성명 이후번텐이 "관중의 아타리와 코모도어 사람들이 애플을 다시 쓰는데 만족하는가?개리엇은 "관객들은 "안돼!"라고 외쳤다. "그렇지 않으면 애플 버전은 완성되지 않을 거야.출판사의 관점에서 그것은 돈에 관한 것이 아니다.[13]

다른 사람들은 다르게 일을 했다.예를 들어, 오자크 소프트스케이프는 포팅하는 동안 필요에 따라 기능을 제거하거나 변경하면서 가장 진보된 컴퓨터를 위해 개발하기를 선호했기 때문에 아타리에 대한 M.U.L.E.를 먼저 썼다.번텐은 "M.U.L.E.는 애플을 위해 할 수 없다"[12]고 했고, 아타리가 아닌 금일곱 도시들은 열등하다고 말했다.[17]Compute!'s Gazette는 1986년에 아타리에서 Commodore로 항해를 할 때 원본이 보통 우위에 있다고 썼다.1983년 말 개발자들이 새로운 소프트웨어를 개발하기 시작했을 때 후자의 게임 품질은 향상되었다고 이 잡지는 말했다.[18]

포팅 아케이드 게임에서는 포팅된 버전의 게임 플레이, 그래픽 및 기타 자산이 아케이드 버전과 얼마나 밀접하게 일치하는지 설명하기 위해 "아케이드 퍼펙트" 또는 "아케이드 정확도"라는 용어를 자주 사용했다.1980년대 초의 많은 아케이드 포트는 홈 콘솔과 컴퓨터가 아케이드 게임에서 정교한 하드웨어가 부족했기 때문에 아케이드 퍼펙트와는 거리가 멀었지만, 게임은 여전히 게임 플레이와 비슷할 수 있다.특히 아타리 VCS스페이스 인베더스는 그 차이에도 불구하고 콘솔의 킬러 앱이 되었고,[19] 후기 팩맨 포트는 아케이드 버전에서 벗어난 것으로 악명이 높았다.[20]아케이드-정확한 게임은 SNK네오 지오 시스템을 시작으로 1990년대부터 더욱 보편화되었는데, SNK의 네오 지오 시스템은 홈 콘솔의 주요 하드웨어를 보다 발전시킨 아케이드 시스템을 모두 제공하였다.이를 통해 아케이드에 가까운 퍼펙트 게임을 홈에서 할 수 있었다.아케이드 하드웨어를 기반으로 한 플레이스테이션드림캐스트와 같은 추가 콘솔은 아케이드 퍼펙트 게임을 현실로 만들었다.[10]

콘솔 포트(console port)는 개인용 컴퓨터에서 재생할 수 있는 동일한 버전이 만들어지기 전에 콘솔용으로 원래 만들어진 게임이다.이 용어는 게임계에서 널리 사용되어 왔다.콘솔에서 PC로 게임을 포팅하는 과정은 컴퓨터가 일반적으로 충분히 활용되지 않는 높은 수준의 성능 때문에 부정적으로 간주되는 경우가 많은데, 이는 부분적으로 실행 내내 콘솔 하드웨어가 고정되어 있기 때문이며, 반면 PC는 하드웨어가 진화함에 따라 더욱 강력해지는 반면, 또한 부정적으로 간주된다.포팅된 게임 때문에 때때로 PC에 잘 최적화되지 않거나, 느리게 포팅되는 경우가 있다.대체로 유사하지만, 콘솔에서 통일된 메모리를 사용하는 것과 같은 구조적 차이가 존재할 수 있다.

참고 항목

메모들

  1. ^ Whitten, D.E.; Demaine, P.A.D. (March 1975). "A machine and configuration independent Fortran: Portable Fortran". IEEE Transactions on Software Engineering. SE-1 (1): 111–124. doi:10.1109/TSE.1975.6312825. S2CID 16485156.
  2. ^ "Portability Issues". .. discusses .. portability of .. Fortran
  3. ^ "port, v.2". Oxford English Dictionary (OED Online). Oxford University Press. Retrieved December 21, 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. ^ 타넨바움 1984, 페이지 3. §1.1 언어,수준 및 가상 시스템에서는 용어와 용어의 관계를 설명한다.
  5. ^ Tanenbaum 1984, 페이지 2. Ch. 1 소개에서는 번역과 해석을 설명한다.
  6. ^ Richards & Whitby-Strevens 1984, 페이지 124. §7.1 소개에서는 중간 코드를 사용한 컴파일러 이식성을 설명한다.
  7. ^ Richards & Whitby-Strevens 1984, 페이지 133.4 §7.4 부트스트래핑 프로세스와 INTCODE는 INTCODE 통역자의 역할을 설명한다.
  8. ^ Richards & Whitby-Strevens 1984, 페이지 136. §7.4.3 예에서는 BCPL 프로그램을 통역자를 위해 INTCOD로 변환하는 예를 제시한다.
  9. ^ Wolf, Mark J. P. (2008). "Glossary". The Video Game Explosion: A History from PONG to Playstation and Beyond. p. 315. ISBN 978-0-313-33868-7.
  10. ^ a b c Grabarczyk, Pawel; Aarseth, Espen (2019). "Port or conversion? An ontological framework for classifying game versions DiGRA Conference 2019". {{cite journal}}:Cite 저널은 필요로 한다. journal=(도움말)
  11. ^ Nicoll, Benjamin (2015). "Bridging the Gap: The Neo Geo, the Media Imaginary, and the Domestication of Arcade Games". Games and Culture. doi:10.1177/1555412015590048. S2CID 147981978.
  12. ^ a b Bunten, Dan (December 1984). "Dispatches / Insights From the Strategy Game Design Front". Computer Gaming World. p. 40. Retrieved 31 October 2013.
  13. ^ a b "The CGW Computer Game Conference". Computer Gaming World (panel discussion). October 1984. p. 30. Retrieved 31 October 2013.
  14. ^ Dunnington, Benn; Brown, Mark R.; Malcolm, Tom (January–February 1987). "64/128 Gallery". Info. pp. 14–21.
  15. ^ Stanton, Jeffrey; Wells, Robert P.; Rochowansky, Sandra; Mellid, Michael, eds. (1984). The Addison-Wesley Book of Atari Software. Addison-Wesley. pp. 12, 21, 44, 126. ISBN 0-201-16454-X.
  16. ^ Bernstein, Harvey (May 1985). "Beyond Castle Wolfenstein". Antic. p. 83. Retrieved 8 January 2015.
  17. ^ Bunten, Dan. "The Game Collection". Ozark Softscape M.U.L.E. Retrieved 2017-10-04.
  18. ^ Yakal, Kathy (June 1986). "The Evolution of Commodore Graphics". Compute!'s Gazette. pp. 34–42. Retrieved 2019-06-18.
  19. ^ Kent, Steven (2001). Ultimate History of Video Games. Three Rivers Press. p. 190. ISBN 0-7615-3643-4.
  20. ^ Kent, Steven (2001). "The Fall". The Ultimate History of Video Games. Three Rivers Press. pp. 237–239. ISBN 978-0-7615-3643-7.

참조