4 - 서브루틴과 함수 (+ 컴파일러)

초기에는 명령코드와 메모리의 위치를 가져와서 레지스터에 넣으면서 기계어 코딩을 했을 것이다.

 

하지만 작업을 하면서 이미 작성한 기능을 다른 프로그램에 가져가서 써야하는 일이 있었을 것이고

동일한 내용의 코드를 작성해야 하는 일이 있었을 것이다.

(전쟁 비용 예시에서 더하는 것을 2번 했던 것처럼)

 

하지만 그런 경우 기능을 옮기려고하는 프로그램의 RAM 위치를 계산해서 코드를 전부 새롭게 짜야했고, 같은 프로그램에서 동일한 내용의 코드를 복사하려고 하더라도 단순 복사가 아니라 RAM 의 위치를 모두 계산해서 코드를 새롭게 작성해야했다. 이는 매우 귀찮고 어려운일이었을 것이다

 

이 문제를 해결하기 위해서 한 가지 아이디어를 가져올 수 있다

 

아무런 영향을 받을 것 같지 않게 '멀리 떨어진' 위치에서 동일하게 쓰일 코드를 작성하면 어떨까?

-> 프로그램의 메인루틴에서 멀리 떨어진 위치에 서브루틴을 작성하는 것. 이게 서브루틴이다.

 

하지만 서브루틴은 여러 문제점이 있었다.

 

1. 호출한 곳과 서브루틴간의 데이터 공유 문제

2. 서브루틴 안에서만 사용하는 데이터의 메모리 낭비 문제

3. 서브루틴에서 다른 서브루틴을 호출하거나, 서브루틴에서 다시 동일한 서브루틴을 호출하는 경우

 

이러한 문제점들을 '스택 포인터' 라는 '개념' 을 통해서 해결했다

 

메모리에 스택 포인터가 사용할 영역을 정해두고, 메인 루틴에서 전달받는 데이터, 서브루틴에서만 사용하는 데이터, 서브루틴 종료 이후에 돌아갈 메모리 위치를 모두 '스택 포인터' 에 대해서 '상대적인' 위치로 저장하는 방식으로 코딩을 하는 것이다. 그리고 서브루틴 종료시에는 다시 메인루틴으로 돌아가도록 하면서 이런 문제를 해결했다.

 

이 스택 포인터라는 개념에서 중요한 것은 '절대적'인 위치를 '상대적' 인 위치로 변경했다는 점이다.

 

예를 들어 메모를하고 책갈피를 꽂아놓은 것을 생각해보자. 내가 특정 메모를 했는데 그걸 몇p 에 했다고 할 수 있지만, 책갈피에서 몇 페이지 떨어진 곳에서 했다고 표시할 수 있는 것과 마찬가지다

 

혹은 책에서 글을 쓸 때 해당 단어가 140 페이지, 33 번째 줄, 1 번째 글자부터 시작한다고 표시하고 찾을 수 있다. 하지만, 만약에 책의 내용이 길어지거나 짧아지개 개정이 된다면, 해당 단어를 찾을 때 몇 페이지, 몇 번째 줄, 몇 번째 글자에 단어가 위치했는지 내용이 수정될 때마다 계산해서 바꿔줘야하지만, 책의 3단원 1페이지 12번째 줄 1번째 글자라고 만 해놓으면 책의 1, 2 단원이 짧아지든, 길어지든 상관없는 것이다. 

 

하지만 이 방법도 아주 만능은 아닌 것이다. 왜냐하면 스택 포인터가 정해진 스택 영역의 범위를 넘어가면 스택 '오버플로우' 가 일어나기 때문이다.

 

이렇게 서브루틴의 단점을 해결한 '스택 프레임' 이라는 기법이 생겨나면서 우리는 반복적이고 귀찮은 작업들을 손쉽게 해결할 수 있게 되었다.

 

다시 처음으로 돌아가서, 같은 기능을 하는 코드를 위해서 RAM 을 다 계산해서 똑같은 코드를 중복으로 짤 필요가 없어진 것이다!!

 

즉, 이렇게 RAM 의 위치를 계산할 필요가 없어지면서, 이 편한 기능을 좀 더 확장하고 싶다는 생각이 들었다

 

이런 일들을 자동으로 하게 해주는 자동화 프로그램에 대한 아이디어가 떠올랐고, 이것이 '컴파일러' 가 되었다.

즉, 사람이 쓰는 말을 기계어로 알아서(RAM 의 위치를 크게 신경쓰지 않아도) 바꿔주는 프로그램을 만들게된 것이다