초기 8bit CPU인 Z80의 경우 assembly는 주변 기기를 직접 제어하기 위한 수단이었으나, (사실 저 시절 c언어 컴파일러는 커녕, 어셈블리 컴파일러도 구할 수 없었고, 내장 basic에서 기계어 코드를 직접 입력하는 식으로 많이 사용하였다. 그나마 저장 장치인 disk drive 도 귀하던 시절이었다) 16bit 시절 8086 / 88 을 사용하면서 디스크 드라이브가 기본이 되었고, ms-dos에 내장된 debug 로 assembly를 맛보다 MASM (micro soft macro assembly)로 넘어오게 되었다.
하지만 참으로 버그도 많았고 (이때 MASM은 가격도 만만했고, 정품을 쓰면서 컴파일러의 버그를 한국 마이크로 소프트에 직접 문제 재기 하기도 하였다) 이 때문에 여기서도 어쩔 수 없이 Op-code 를 분석 할 수 밖에 없었다.
32bit 이후로는 assembly compiler 는 믿을 수 있게 되어 굳이 op-code를 외우면서 쓸 일은 없어졌지만, 호환성 등의 문제가 생길 때 마다 간간히 비교를 하게 되었다.
한 때 CISC 와 RISC 는 서로 논쟁을 벌이며 지금까지 오고 있지만, 누가 승자라고 할 수 없었고,
지금과 같은 64bit 에서 일정한 크기로 op-code를 만든다는 것은 기본 크기가 커져 의미도 없고, 오히려 코드 크기를 줄여 용량과 속도를 잡으려는 ARM 의 thumb mode 와 같은 시도가 있는 상황에서는 의미가 없어지게 되었다.
RISC-V는 32bit 로 정렬된 정통 RISC 를 표방하려.. 하였으나..
(출처: riscv-spec ver2.2)
위에서 설명한 것과 같이 ARM의 thumb 모드와 같이 코드의 밀도를 높이는 것이 유행이다 보니 16bit 단위의 가변 크기 코드를 기본 지원하고 있다.
물론 RISC가 코드 크기 정렬만으로 말할 순 없지만, CISC의 내가 아는 유일한 아키텍쳐인 x86 역시 코드를 일정 크기로 디코딩하여 파이프라인에 넣는 방식으로 가고, 64bit로 와서는 불필요한 명령들을 삭제하는 분위기이기 때문에 굳이 RISC냐 CISC냐의 구분은 예전 세대의 일로 생각된다.
다시 돌아와, RISC라 해도 요즘 같이 다양한 기능을 요구하는 세상에서 정형화 된 크기에 모든 기능을 다 넣는다면 기본 OP-CODE크기가 매우 커져야 하고, 그것은 불필요한 메모리 낭비와 속도 저하로 이어지게 된다.
그렇다고 예전 x86시절과 같이 기본 단위 크기도 없는 난잡한 op-code 크기는 branch 예측등과 같이 속도 증가를 위한 설계를 매우 복잡하게 만든다.
어느 정도 룰을 가지고 가고 예외를 적당히 추가하는 것이 이상적이지 않을까 생각 된다.
나는 CPU반도체 개발자가 아니다 보니, 프로그래머 입장에서 얇은 지식으로 이러면 좋지 않을까 라는 생각을 하고 있었는데, RISC-V는 이런 여러가지 이론적인 바람들을 현실로 구현하는 듯한 부분들이 많았다.
근래 들어 RISC-V 아키텍쳐를 채용한 SOC 제품들이 보이기 시작했고, 거래처 중 두 곳에서 RISC-V로 제품을 내놓았다.
이 중 한 업체의 SOC를 채용하여 제품 화 해본 결과 생각보다 생각 이하의 성능과 안정성에 실망이 컷다.
물론 칩 제조사의 실수와 한계로 인한 부분도 있지만, 공개 아키텍쳐의 한계 또한 있었다.
지금은 어느 정도 안정화 하여 사용하고 있지만, 성능의 한계는 어쩔 수 없었고, 이와 관련하여 칩 업체와의 미팅에서 이야기를 나눌 기회가 있었다.
RISC-V가 국내에서 아직 활성화가 어려운 이유를 정리해 보면 다음과 같았다.
1. 부가 가속 기능에 대한 표준화가 어렵다. ARM이나 X86의 경우 SIMD와 같은 가속 계열 명령이 어느 정도 표준화 되어있고 기본 탑재가 되어있어 요즘같이 대량의 멀티미디어나 수집 데이터를 처리할 일이 많을 경우 처리 속도에서 이득을 볼 수 있다.
하지만, RISC-V의 SIMD에 해당하는 벡터 연산은 표준화가 최근 들어 합의 되었고, 그나 마도 옵션이기 때문에 채택하지 않은 칩들이 많다. 아마도 기본 부분 안정화도 어려운데, 해당 기능까지 적용할 여유가 없어서 인 듯 하다.
2. RISC-V 숙련된 개발자를 구하기 어렵다. 특히 중소기업의 경우 해당 반도체 설계 엔지니어를 구하기는 어렵고, 어떻게 구해도 주로 대기업을 가기 전에 실습 해 보기 위한 거쳐가는 과정으로 있다 가는 사람들이 많다고 한다. 실제 거래처 중 한 곳 역시, RISC-V 코어 개발자 분이 제품 하나를 만들고 이직을 하여, 더 이상 RISC-V 코어 부분은 건들지 못하고 주변 기능만 변경하여 내보내고 있다 하였다. 결국 RISC-V로는 일부 모델만 추가로 내놓고, 라이선스 비용을 내더라도 ARM으로 변경하는 부분을 고민한다 하였다.
3. ARM이라는 완성된 선택지가 있다. 거래처들은 RISC-V가 무료 아키텍처라는 점에 혹하여 도전하였다가, 엔지니어 확보 및 타 아키텍쳐와 성능 경쟁을 하기 위해 투자해야 하는 비용을 겪고 나면, 비록 라이선스 비용이 있지만 이미 완성된 ARM을 사용하는 것이 적은 인력으로 개발해야 하는 중소기업이나 중견기업 입장에서는 더 나은 선택일 수 있다고 말하였다.
대 부분 중소, 중견 기업의 경우 CPU 제조사가 아닌, 특정 작업을 잘 하는 SOC의 개발을 주로 하는데, CPU아키텍쳐에 투자하는 것 보다, 아키텍쳐는 믿을만하고 성능 나오는 ARM같은 아키텍쳐를 사용하고, 주요 기능의 기술 개발에 투자하는 것이 좋을 수 있다는 이야기였다.
나 같은 특이한 것을 좋아하는 개발자는 ARM이나 x86과 같은 대기업 주도의 제품보다 새롭고 창의 적인 것을 좋아하다 보니 RISC-V에 호감이 많이 가지만, 생업이 우선이다 보니 현재로선 RISC-V를 밀 용기가 나지 않는다. 결국 현재 RISC-V제품으로는 저가형 일부 모델에만 채용하고, 차기 제품으로는 다시 ARM 아키텍쳐를 검토하고 있는 중이다.
처음에는 미미했던 open source의 linux 가 급 성장 한 것 처럼, RISC-V도 지금은 미미하지만 어느 정도 때가 무르익으면 급성장 하지 않을까 하는 생각을 가지고, 앞으로도 지켜볼 생각이다.
댓글 없음:
댓글 쓰기