초기 어셈블러는 A라는 컴퓨터에 대한 어셈블러를 기계어로 만들고 B라는 컴퓨터에도 어셈블러를 새로 만들어야 해서 A의 어셈블러를 새로운 어셈블러를 작성 했다는데
c언어는 어케 이런짓 안하고 다 실행이됨? 아니면 모든 컴퓨터에 대해 이런짓을 한거임?
댓글 17
후자임
ㅎㅇ(223.38)2025-02-14 20:52
답글
그럼 새로운 cpu가 나올때마다 컴파일러를 업데이트해야함?
익명(223.38)2025-02-14 20:54
답글
키워드: instruction set architecture
익명(106.101)2025-02-14 20:59
해당 댓글은 삭제되었습니다.
해당 댓글은 삭제되었습니다.2026-07-28 22:24
답글
뭔소리임
익명(223.38)2025-02-14 20:54
대부분의 프로세서 회사들이 c 정도는 지원하는걸 목표로 해서 자기들이 컴파일러 만들어서 제공하기 때문에 c의 이식성이 좋다고 하는걸로 알고 있음. 어디 하꼬 쩌리 프로세서는 c언어 그딴거 없고 지들만의 어셈블리 명령어 셋으로 직접 프로그램 작성해야할 수도 있겠지. - dc App
익명(110.8)2025-02-14 21:02
표준을 만들고 컴퓨터 부품이 그걸 지원하게 하면 됨
익명(118.235)2025-02-14 21:58
답글
머리가 띵해졋오
익명(223.38)2025-02-14 22:02
컴구 ㄱㄱ
땔감(gcp24685)2025-02-14 22:12
답글
그런거 안배우고 군지해서..
익명(223.38)2025-02-14 22:25
당연히 개 씹 고인물 능력자 분들이 컴파일러를 잘 만들어둬서 거의 모든 아키텍쳐에서 c언어가 컴파일 될수있게 되서 그러지
익명(121.185)2025-02-15 00:47
답글
어셈블리어는 각 아키텍쳐 마다 다 달라서 x86에서 컴파일한 프로그램은 당연히 arm이나 risc-v에서는 실행하지 못함. 그 대신 썩은물들이 각 아키텍쳐별로 컴파일러를 다 만들어줘서 우리가 아키텍쳐 별로 신경안쓰고 편하게 로우레벨 프로그래밍을 할수 있게된거
익명(121.185)2025-02-15 00:50
어셈에서 시작해야 된다는건 오해고 이미 잘 작동하는 언어가 있으면 그걸로 하면 됨 그 언어에서 잘되면 그 언어가 어셈블까지 해줄거임 그래서 그걸로 새로운 언어의 컴파일러를 만들고 그걸 자꾸 버전업 시켜서 그 언어를 직접 컴파일할 수 있게 만들고 그게 가능해 지면 기존에 컴파일러 만들던 언어는 버리고 새로운 그 언어로만 계속 작업하면 됨
C 언어는 특정 하드웨어에 종속되지 않고, 컴파일러를 통해 각 플랫폼의 기계어로 변환됨. 이를 위해 각 CPU 아키텍처마다 C 컴파일러(예: GCC, Clang, MSVC)가 존재하며, 해당 컴파일러는 C 코드를 해당 플랫폼의 명령어 집합(ISA, Instruction Set Architecture)에 맞게 번역함. 또한, 운영체제별 차이를 줄이기 위해 C 표준 라이브러리(libc)가 제공되며, 이는 OS별 시스템 호출(Syscall)이나 API를 추상화하여 동일한 인터페이스를 유지함.
익명(121.65)2025-02-15 18:48
답글
결국, 각 하드웨어마다 C 컴파일러를 새로 만들었지만, 한 번 만든 이후에는 C 코드가 이식성을 유지하면서 동작할 수 있는 구조가 됨. 이러한 방식 덕분에 C는 어셈블리처럼 각 하드웨어마다 새로 작성할 필요 없이, 한 번 작성된 코드를 다양한 환경에서 실행할 수 있는 "컴파일 기반 이식성"을 갖게 됨.
익명(121.65)2025-02-15 18:48
내용을 다시 보니까 컴파일러를 어떻게 만들었냐는 질문이 아니고 왜 소스코드 레벨에서 하드웨어간 호환이 유지되냐는 질문이었구만 C로 짠다고 엔디안부터 다를 수 있으니 100% 호환되는건 아니고 예를 들어보자면 어셈으로 A머신과 B머신의 비교와 점프 명령이 다를 순 있지만 소스 코드가 그런 어셈 명령을 직접 쓰는게 아니고 if나 while같은걸로 되어 있고 그걸 보고 컴파일러가 해당 머신의 어셈으로 바꿔주는거기때문에 소스코드레벨에선 호환됨
후자임
그럼 새로운 cpu가 나올때마다 컴파일러를 업데이트해야함?
키워드: instruction set architecture
해당 댓글은 삭제되었습니다.
뭔소리임
대부분의 프로세서 회사들이 c 정도는 지원하는걸 목표로 해서 자기들이 컴파일러 만들어서 제공하기 때문에 c의 이식성이 좋다고 하는걸로 알고 있음. 어디 하꼬 쩌리 프로세서는 c언어 그딴거 없고 지들만의 어셈블리 명령어 셋으로 직접 프로그램 작성해야할 수도 있겠지. - dc App
표준을 만들고 컴퓨터 부품이 그걸 지원하게 하면 됨
머리가 띵해졋오
컴구 ㄱㄱ
그런거 안배우고 군지해서..
당연히 개 씹 고인물 능력자 분들이 컴파일러를 잘 만들어둬서 거의 모든 아키텍쳐에서 c언어가 컴파일 될수있게 되서 그러지
어셈블리어는 각 아키텍쳐 마다 다 달라서 x86에서 컴파일한 프로그램은 당연히 arm이나 risc-v에서는 실행하지 못함. 그 대신 썩은물들이 각 아키텍쳐별로 컴파일러를 다 만들어줘서 우리가 아키텍쳐 별로 신경안쓰고 편하게 로우레벨 프로그래밍을 할수 있게된거
어셈에서 시작해야 된다는건 오해고 이미 잘 작동하는 언어가 있으면 그걸로 하면 됨 그 언어에서 잘되면 그 언어가 어셈블까지 해줄거임 그래서 그걸로 새로운 언어의 컴파일러를 만들고 그걸 자꾸 버전업 시켜서 그 언어를 직접 컴파일할 수 있게 만들고 그게 가능해 지면 기존에 컴파일러 만들던 언어는 버리고 새로운 그 언어로만 계속 작업하면 됨
https://en.wikipedia.org/wiki/Bootstrapping_(compilers)
C 언어는 특정 하드웨어에 종속되지 않고, 컴파일러를 통해 각 플랫폼의 기계어로 변환됨. 이를 위해 각 CPU 아키텍처마다 C 컴파일러(예: GCC, Clang, MSVC)가 존재하며, 해당 컴파일러는 C 코드를 해당 플랫폼의 명령어 집합(ISA, Instruction Set Architecture)에 맞게 번역함. 또한, 운영체제별 차이를 줄이기 위해 C 표준 라이브러리(libc)가 제공되며, 이는 OS별 시스템 호출(Syscall)이나 API를 추상화하여 동일한 인터페이스를 유지함.
결국, 각 하드웨어마다 C 컴파일러를 새로 만들었지만, 한 번 만든 이후에는 C 코드가 이식성을 유지하면서 동작할 수 있는 구조가 됨. 이러한 방식 덕분에 C는 어셈블리처럼 각 하드웨어마다 새로 작성할 필요 없이, 한 번 작성된 코드를 다양한 환경에서 실행할 수 있는 "컴파일 기반 이식성"을 갖게 됨.
내용을 다시 보니까 컴파일러를 어떻게 만들었냐는 질문이 아니고 왜 소스코드 레벨에서 하드웨어간 호환이 유지되냐는 질문이었구만 C로 짠다고 엔디안부터 다를 수 있으니 100% 호환되는건 아니고 예를 들어보자면 어셈으로 A머신과 B머신의 비교와 점프 명령이 다를 순 있지만 소스 코드가 그런 어셈 명령을 직접 쓰는게 아니고 if나 while같은걸로 되어 있고 그걸 보고 컴파일러가 해당 머신의 어셈으로 바꿔주는거기때문에 소스코드레벨에선 호환됨