프로그램언어에 대한 질문입니다. 고수님들 답변부탁드립니다.
글쓴이: gyxor / 작성시간: 일, 2003/04/13 - 7:26오후
1.
또한 맨처음 기계어에서 처음 탄생한 언어가
어셈블리어인가요?
어셈블리어를 .exe 기계어 실행파일로 어셈블링 해주는
그 "어셈블러"는 기계어로서 짜여진 것인가요?
2.
비슷한 질문입니다만
컴퓨터라는것에 최초의 원리를
찾는다면은 결국 형광등이 들어오고 나가듯이 ..
켜짐과 꺼짐 .. 이 두가지의 서로다른 상태에서 출발한다고
알고있습니다. 이런게 하나둘 뭉쳐서 비트에서 바이트
결국 기계어가 탄생하고 그다음이 기계어이고 어셈블리언어
라고 하는데요
그 연결고리가 되는 부분이 궁금한것입니다.
기계어와 어셈블리어의 연결고리
기계어를 통해서 어셈블러를 만들어내고 그래서 그것을
토대로 어셈블리언어로 프로그램을 작성하게 된것인가요?
다시말해서 기계어를 가지고 어셈블러를 개발해서 그것에 맞춰
어셈블리언어가 생겨난것이구요
그러니까 어셈블러와 어셈블리어 순서를 굳이 따지자면
어셈블러가 먼저가 아닌가 하는것입니다.
3.
기계어로 어셈블러를 만들었듯이
마찬가지로 (그외 다양한)컴파일러를 만든것은 어셈블리어인가요?
이 부분이 궁금했습니다.
답변부탁드려요
4.
또한 어셈블리어 앞에는 어떠한 언어가 있었으며
그 뒤로 c언어에 이르기까지의 계보가 궁금합니다.
- [어셈블리어] - - [CPL] - [BCPL] - [B] - [C] - [C++] - [JAVA] ,[C#]
이게 맞는가요?
네가지 질문입니다. 고수님들께서
답변해 주시면 감사하겠습니다.
Forums:
CPU마다 다른 기계어는 해당 CPU의 어셈블러와 직접 매칭되는 관계입니
CPU마다 다른 기계어는 해당 CPU의 어셈블러와 직접 매칭되는 관계입니다. 즉 단순하게 기계어의 비트를 그나마 좀 알기 쉽게 표현해 놓은 것이 어셈블리 언어가 됩니다.
그럼 어셈블러는... 기계어로 직접 작성할 수 있습니다. :) 아니면 해당 CPU의 어셈블리 언어를 사용하여 종이나 파일에 직접 쓰고 나서 손으로 기계어로 번역해도 됩니다.
요즘에는 너무 고수준 환경만 접하시므로 그런 원초적인 환경을 접하기가 어렵지만, 지금도 임베디드 환경 또는 저수준의 OS서비스를 만들어야 하는 경우에는 어셈블리 언어를 직접 다루어야 하는 경우가 있습니다.
또한, 예전에 8비트 컴퓨터를 꽤 만져 보신 분들은 아시겠지만 베이직 인터프리터 자체가 어셈블리 언어로 작성이 되어 있었습니다. 또한 모니터라고 많이 부르던 기계어 유틸리티 프로그램도 약간의 기계어 코드를 알고 컴퓨터의 BIOS의 엔트리 루틴을 약간 만질 줄 알면(화면 입출력 정도) 그리 어렵지 않게 모니터를 작성할 수 있었습니다(dump랑 입력 되는 정도죠). 그 다음에는 모니터를 갖고 어셈블러를 작성하고(종이에 코드를 작성하고 손으로 기계어로 컴파일할 수 있습니다. Z80이면 그정도는 약간의 노력이 있다면 가능했습니다. 약 4-5페이지 정도 되는 표만 있다면. 인텔도 8086정도는 그리 어렵지 않았습니다), 어셈블러가 갖추어지면 어셈블리 언어를 사용하여 베이직 인터프리터나 C언어 컴파일러를 직접 작성할 수 있습니다. 그 다음으로 계속 고수준 언어 환경으로 이동하는 것이겠지요.
--
익스펙토 페트로눔
지금 쓰고 있는 컴들이 폰노이만 아키텍쳐를 따르다 보니 이런식으로 발전하
지금 쓰고 있는 컴들이 폰노이만 아키텍쳐를 따르다 보니 이런식으로 발전하지 않았나 라고 생각이 드는군요.. 뭔소리고 하니
M/M에 program routine들이 빼곡이 들어박혀야 되니 memory에 주소가 필요해지고 memory maped I/O같은 개념때문에 수많은 인터럽트가 생겨나고 했는데 이러한 것이 생겨나게 된것은 (뭔가 먼저니 뭔가 뒤니.. 이런건 모르겠구..) 폰노이만 아키텍쳐 덕인듯합니다. 지금까지는 잡설이고요. ㅡㅡa
exe파일은 script언어로 쓰여진 파일과 비교해 보면 뭔가 생각이 나실겁니다.
시스템에 대한 이해가 없더라도 말이죠..
script는 자체가 실행될수 있는 능력이 없다보니 script를 해석해 주는 인터프리터가 중간에서 실행할수 있는 형태로 바꾸어 주는 것이지요. 그렇다면 이러한 과정이 없는 exe파일같은경우는 인터프리터언어에서처럼 해석을 해줄 필요가 없는 형태라고 생각할수 있겠죠..
글구 기계어랑 어셈이랑 뭔가 알이냐 닭이냐 하는거는.. system archtecture를 배우시면 아시겠지만 일정한 bit pattern의 instruction을 어떻게 표현하는가 하는 면에서 서로 나누어진다고 보시면 조금편할겁니다. 먼저 cpu에서 알아먹을수 있는형태 (cpu중에서 cu이겠죠..) 특정 명령을 수행할수있는 bit pattern을 생성해야되는데 이러한 녀석들이 폰노이만 아키텍쳐를 효율적으로 사용하기 위해 registry와 memory를 이용하기때문에 우리가 일반적으로 알고 있는 어셈명령어들에 +alpha가 되어서 다양한 기계어가 생성이 되는것이죠.. 말이 좀 애매한듯한 한데 mips 관련책이 있는데 함 보시면 쉽게 이해가 되실겁니다. 직접 구조를 생성하고 instruction을 만들고.. assembler를 만드는것도 가능하지요..
컴파일러는 뭘로 만들든 관계가 없습니다. 능력이 된다면야 어셈으로 만들어도 되겠지만 lex,yacc이 지원되는 C/C++, java등을 사용하는 것이 편하겠지요. 어째껀 컴팔러라는 것은 자신이 만든 특정 문법에 따른 어셈 코드를 생성해 주는 것일 뿐이니까요.. 이건 dragon book을 참조하십시요..
어셈블리 앞에 어떤언어가 있었냐? 이건.. 어떤 아키텍쳐가 언제 만들어 졌냐에 따라 답이 틀려지겠네요. 어셈은 아키텍쳐에 맞게 생성이 되는것이다 보니 새로운 아키텍쳐가 나온다면 당연 새로운 어셈이 생길테니 까요..C#보다 새로운 어셈도 생길수 있다는 거죠 ^^
대충걀겨 썼는데 도움이 되셨을랑가 모르겠네용.. 그럼이만...
평온하다~
Computer Architecture 책을 하나 보시면 도움이 될것 같
Computer Architecture 책을 하나 보시면 도움이 될것 같네요.
Instruction Set Architecture 쪽을요.
( 이런걸 보고 나면 x86이 정말 엉망이란 생각을 하게 되죠. )
사실 기계어가 먼저라기보다는,
사람에게 필요한 Instruction들을 설계-정의하고,
( 대개 이것이 Assembly Language의 형태가 되겠죠. )
그 이후에 이 Instruction들을 Decoding하기 쉽게 기계어를 설계하죠.
이미 설계해놓은 Assembly Language를 위한 Assembler를 만드는 것은
그 다음의 일이 될 것이고요.
먼 옛날 가산기 정도의 역할만 하던 때엔,
당연히 기계어가 먼저였겠습니다만,
( Assembly Language랄 것이 없으니까요. )
현재 새로운 Architecture를 만들 땐 그렇게 하지 않겠죠.
답변만 간단히 드리면
1. 최초의 언어가 어셈블 인지 아닌지는 잘 모릅니다. (아마 그럴겁니다만)
예전에 8비트 다룰때만해도 어셈블러없이 기계어 니모닉 코드를 다 외워서
했었습니다. ( 물론, 비트계산은 수동으로... 80년대 중반만해도 월간
마이크로소프트웨어에서 주최하는 1라인 컨테스트 -- 255바이트
안에서 기계어 코드로 작성하는 공모전-- 같은걸로 퀵소트에 게임에 별별거
다만들었습니다.) 저수준이라 해서 최초라는 보장은 없을듯 합니다.
-- 잡담입니다만... 그당시에 삼성spc의 한자코드 (몇천자인지는 잘 모름)
까지 다 외우는 전설적인 분도 계셨습니다. --
어셈블리는 기계어로 만들 필요가 없습니다. (물론, 최초의 어셈블러는
기계어로써 만들었을것입니다) 기계어로 만들어져 있지 않은 어셈블러들이
더 많습니다. ( gas 도 C source 인가요? )
2. 굳이 답변이 필요없지 않을까 합니다.
3. C 컴파일러를 C 로 만들기도 하고, 파스칼을 파스칼로 만들기도 합니다.
(델파이도 델파이로 만듭니다. 델파이용 lex/yacc도 있고, 델파이로 C를
만들수도 있습니다. 최초의 델파이는 C로 구현되었을겁니다. )
물론, java같은 bytecode generator로써 컴파일러를 구현하는 것은
불가능합니다. (java vm을 사용하는 컴파일러? oh... )
4. 언어의 계보에 관한것은 1983년도즈음에 컴퓨터비젼이라는 잡지에서
한번 다룬 특집을 본것이 전부인데 20년전이라서 기억이 가물가물...
어쨌든 기억나는대로하면 1957년에 Fortran이, 1960년에 Basic 이
만들어졌습니다. 컴파일러까지 그때 구현되었는지는 잘 모릅니다.
-- 언어가 설계된것과 그 컴파일러가 구현된 것은 좀 다릅니다.
현대적인 언어들도 specification과 implementation 을 구분합니다. --
homeless
Re: 답변만 간단히 드리면
자바 컴파일러인 javac는 JVM 위에서 돌아갑니다. 원한다면 JVM 위에서 돌아가는 C++ 컴파일러를 짤 수도 있습니다. 어떤 언어냐, 어떤 기계에서 돌아가느냐는 전혀 관계가 없습니다. 컴파일러는 주어진 소스파일을 원하는 기계의 언어로 바꿔주는 프로그램일 뿐입니다. Intel CPU 위에서 SPARC이나 ARM용 파일을 컴파일할 수 있는 것과 마찬가지로요.
그리고 최초의 델파이 컴파일러는 아마도 터보 파스칼로 구현되지 않았을까요?
Re: 답변만 간단히 드리면
현재의 델파이는 델파이와 C++Builder를 함께 사용해서 구현된 것으로 알고 있습니다. 물론 C++Builder도 마찬가지고요.
Re: 프로그램언어에 대한 질문입니다. 고수님들 답변부탁드립니
1.
또한 맨처음 기계어에서 처음 탄생한 언어가
어셈블리어인가요?
어셈블리어를 .exe 기계어 실행파일로 어셈블링 해주는
그 "어셈블러"는 기계어로서 짜여진 것인가요?
C 이전에 전부가 아니라 일부 코어한 부분만 binary로 작성되고 나머지 부분은 어셈블리로 작성이 되었을 겁니다. 추가적인 좀더 새부적인 기능은 사용이 좀더 편리한 어셈블리어로 작성이 되었겠지요.
2.
비슷한 질문입니다만
컴퓨터라는것에 최초의 원리를
찾는다면은 결국 형광등이 들어오고 나가듯이 ..
켜짐과 꺼짐 .. 이 두가지의 서로다른 상태에서 출발한다고
알고있습니다. 이런게 하나둘 뭉쳐서 비트에서 바이트
결국 기계어가 탄생하고 그다음이 기계어이고 어셈블리언어
라고 하는데요
그 연결고리가 되는 부분이 궁금한것입니다.
기계어와 어셈블리어의 연결고리
기계어를 통해서 어셈블러를 만들어내고 그래서 그것을
토대로 어셈블리언어로 프로그램을 작성하게 된것인가요?
다시말해서 기계어를 가지고 어셈블러를 개발해서 그것에 맞춰
어셈블리언어가 생겨난것이구요
그러니까 어셈블러와 어셈블리어 순서를 굳이 따지자면
어셈블러가 먼저가 아닌가 하는것입니다.
1번 답변과 같은 내용일 듯...
3.
기계어로 어셈블러를 만들었듯이
마찬가지로 (그외 다양한)컴파일러를 만든것은 어셈블리어인가요?
이 부분이 궁금했습니다.
답변부탁드려요
이것도 답변이 비슷한데...
우선은 C를 예를 들면...
C는 기본적인 코어한 부분은 당연히 어셈블리로 작성이 되었습니다. 그런 후 이 컴파일러(C)로 C코드를 추가 하면서 좀 더 기능을 추가 해가는 식으로 작업을 하였습니다.
한 번씩 C로 살을 붙일 때 마다 새로운 기능이 늘어나고...
이런 식으로 작업을 하니..
우리가 보기엔 C컴파일러도 C로 짰다고 봐도 과언이 아닐 듯 하네요...
4.
또한 어셈블리어 앞에는 어떠한 언어가 있었으며
그 뒤로 c언어에 이르기까지의 계보가 궁금합니다.
- [어셈블리어] - - [CPL] - [BCPL] - [B] - [C] - [C++] - [JAVA] ,[C#]
이게 맞는가요?
이 부분은 다른 곳에서 찾아 봐야 할 듯...-_-ㅋ
이런걸 외우는건 좀...-_-ㅋ
네가지 질문입니다. 고수님들께서
답변해 주시면 감사하겠습니다.
#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);
댓글 달기