오브젝트 코드를 사용하지 않는 언어가 있다면 어떤 평가를 받을 까요?

C언어로 프로그래밍을 할 때 오브젝트 코드(파일)은 프로그래밍에 많은 도움을 줍니다.

가장 많이 쓰는 부분은 누가 뭐라고 해도 수많은 라이브러리 파일들을 링킹해서 사용하는 것이지요.

그래서 보통 실행파일이 만들어지는 과정을 설명하면

소스코드 ---(컴파일러)---> 어셈블리어 ---(어셈블러)---> 오브젝트 코드 ---(링커)---> 실행파일

이렇게 설명되곤 합니다.

이 오브젝트 코드(파일)의 형태(포멧)은 플랫폼 별로 혹은 링커에 따라 다양하게 존재합니다.

링커는 여러개의 오브젝트 파일을 재배치하여 하나의 기계어 파일(실행파일)로 만들어 주는 역할을 하지요.

전에 제가 올렸던 글에 쓴것 처럼 요즘 저만의 언어+컴파일러+vm을 만들고 있습니다.

그 과정에서 재배치 정책을 설계 하려다 보니 오브젝트 코드(파일)의 형태(포멧)을 정하는 부분이 참 애매하더라구요.

그래서 그냥 오브젝트 코드(파일) 없이

소스코드(고급언어로 작성된 코드, 여러개) ------> 심볼테이블을 포함하는 어셈블리 코드(여러개) ------> 심볼테이블에 따라 재배치를 완료하여 하나로 만들어지고 모든 레이블이 주소로 치환된 어셈블리 코드(한개) ------> 기계어 코드(한개)

이런식으로 정리되더라구요. 그러다 보니 저 위에 있는 '컴파일러 ---> 어셈블러 ---> 링커' 의 분류로 봤을 때, 어셈블러와 링커의 순서가 바뀌거나 혹은 어셈블러와 링커의 역할이 하나로 합쳐져 버리는 결과가 나와 버리는 겁니다.

그래서 고민입니다.

굳이 오브젝트 코드라는 단계를 만들어서 어셈블러와 링커의 역할을 확실히 분리 해야 하나...
아니면 그냥 저대로(즉, 제 맘대로) 진행해 버릴까...

한 삼일 정도 고민해 본 결과, 제 스타일대로 오브젝트 코드 없이 '레이블과 심볼테이블을 하나에 가지는 어셈블리 코드'(이것을 일종의 오브젝트 코드라고 볼 수도 있겠네요), '심볼테이블은 사라지고 레이블은 주소로 치환된 어셈블리 코드' 이렇게 나눠도 라이브러리 링킹같은 동작은 무리없이 될것 같거든요.
(라이브러리의 코드 보안과 같은 문제는 생각하지 않는다는 것을 전제로 두고 있습니다.)

다만 저렇게 될 경우 '컴파일러 ---> 링커 ---> 어셈블러' 이렇게 논리적인 동작순서가 일반적인 경우와 반대로 된다는 문제가 생기게 됩니다.

뭔가 제가 전제를 잘못하고 있는것 같기도 하고 해서, 이렇게 KLDP에 넋두리삼아 올려 보네요.

아직 코딩은 한줄도 하지 않고 저런 문제를 핑계로 일주일 넘게 vi 화면만 띄워놓고 있는 중입니다...^^