인라인 어셈블리를 공부하면서 느낀 점이야.
그거야 말로
루틴의 정의야
인라인 어셈블리라는게 결국 뭐야??
컴파일러에게
"인풋을 바인드해줘"
"아웃풋을 바인드해줘"
내가 인풋과 아웃풋을 가지고 어떻게 가지고 놀던지 안에서 캡슐화 되어있으니 너는 신경쓸거 없어.
이거잖아.
이게 루틴이야
도대체 이렇게 좋은 루틴의 정의방법을
도대체
함수는 어째서
인자를 받아들여서 하나로 내보내는거야???
그러다보니까
이상하잖아.
함수의 인자로는 다 똑같은 변수들을 받아들인다고 쳐봐,
근데 인라인 어셈블리상으로는 그새끼들중 일부는
"=r" 이고
일부는
"r" 이야
아웃풋이 인풋이랍시고 들어가있고
return 은 쓰잘데기없이
"에러가 아니에요!! 축하해요!" 를 의미하는
0 반환을 하는데,
함수라 하면
인풋이 들어가서 아웃풋이 나오는 구조 아니냐??
그리고 함수라는게 아웃풋이 1차원이어야하는 이유도 없고.
그냥 인라인 어셈블리에서 input, output, clobber
이 세가지의 구조물이 루틴의 정의라고.
그리고, 캡슐화 된 내부에서 다시 내부변수들이 존재하는거고.
난 그래서
모든 변수를
input
output
inner
clobber
이렇게 네가지로 구분하려고 해.
명쾌하잖아?? 안그래??
함수 형태 표기 개 복잡할듯
생산성측면에서는 말이 안되는 이야기긴 해 ㅋㅋㅋㅋ 근데, 오히려 나는 함수를 생산성이 좋게 만들었기 때문에 가독성이 부족하다는 생각을 하고 있어 인라인어셈블리의 루틴표기방식은 가독성이 정말 좋단말이야. 아 뭐 뭐가 들어가고, 뭐 뭐가 나오는구나!! 진짜 가독성이 좋아
그 내부 캡슐화되어있는 명령어들의 가독성이 쓰레기라 그렇지 ㅋㅋㅋㅋ 그냥 캡슐 안쪽은 캡슐화되어있다고 생각하고 시그니처만 보면 ㅇㅇ 대충 너 뭐 하는애구나? 이런게 바로 보이잖아
물론, C에서도 대충 & 로 넘겨준 애들이 output이겠구나, 그냥 넘겨준 애들은 input이겠구나~ 하면 편하지 ㅋㅋㅋㅋ 근데, &가 "=r" 인지 "+r" 인지는 내부를 들여다봐야지 알수있고
또, 그냥 포인터변수를 집어넣으면 아웃풋변수인데, 인풋으로 오해하고 넘어갈수도있음. 무엇보다도, 실사용례에서, 변수 앞에 &를 붙였느냐 안붙였느냐로 티나는거지 함수 시그니처만 봐서는 해당 포인터가 input 인지 output인지를 알수가 없어
그게 제일 크지. 함수 시그니처를 보고 내가 직접 함수 안의 코드를 까서 보지 않는 이상, 해당 변수로 들어간게 인풋인지 아웃풋인지를 모르는데 이게 말이 돼??? 캡슐화가 안되어있잖아 코드가