shopkeeper/korean_wiki_content_only_120125 huggingface dataset:
자바에서는 스레드 지역 변수가 클래스 객체에 의해 구현된다. ThreadLocal은 T 타입의 변수를 저장하며, 이는 get/set 메서드를 통해 접근할 수 있다. 예를 들어, Integer 값을 저장하는 ThreadLocal 변수는 다음과 같다.
private static final ThreadLocal&lt;Integer&gt; myThreadLocalInteger = new ThreadLocal&lt;Integer&gt;();
적어도 Oracle/OpenJDK의 경우, 자바 스레딩의 다른 측면에서 OS 스레드가 사용되더라도 이는 네이티브 스레드 로컬 스토리지를 사용하지 않는다. 대신, 각 Thread 객체는 ThreadLocal 객체에서 해당 값으로 매핑되는(Thread 객체에서 값으로 매핑되는 ThreadLocal을 가져와 성능 오버헤드를 발생시키는 것과 반대) (스레드 안전하지 않은) 맵을 저장한다.
.NET 언어: C# 및 기타.
닷넷 프레임워크 언어(예: C 샤프)에서는 정적 필드를 ThreadStatic 속성으로 표시할 수 있다.
class FooBar
[ThreadStatic]
private static int _foo;
.NET Framework 4.0에서는 System.Threading.ThreadLocal&lt;T&gt; 클래스를 사용하여 스레드 지역 변수를 할당하고 지연 로딩할 수 있다.
private static System.Threading.ThreadLocal&lt;int&gt; _foo;
또한 스레드 지역 변수를 동적으로 할당하는 API도 사용할 수 있다.
오브젝트 파스칼.
오브젝트 파스칼 (델파이) 또는 프리 파스칼에서는 'var' 대신 'threadvar' 예약어를 사용하여 스레드 로컬 스토리지를 사용하는 변수를 선언할 수 있다.
mydata_process: integer;
threadvar
mydata_threadlocal: integer;
코코아, 그누스텝, 오픈스텝에서 각 codice_30 객체는 스레드의 codice_31 메서드를 통해 접근할 수 있는 스레드 지역 사전을 가지고 있다.
NSMutableDictionary *dict = [[NSThread currentThread] threadDictionary];
dict[@"A key"] = @"Some data";
[[펄]]에서는 언어 진화 후반에 스레드가 추가되었는데, 이미 [[CPAN]]에 많은 기존 코드가 존재한 이후였다. 따라서 펄에서는 기본적으로 모든 변수에 대해 자체 지역 저장소를 가져와 스레드가 기존의 스레드 비인식 코드에 미치는 영향을 최소화한다. 펄에서 스레드 공유 변수는 속성을 사용하여 생성할 수 있다.
use threads::shared;
my $localvar;
my $sharedvar :shared;
퓨어베이직.
[[퓨어베이직]]에서 스레드 변수는 Threaded 키워드로 선언된다.
Threaded Var
[[파이썬]] 버전 2.4 이상에서는 threading 모듈의 local 클래스를 사용하여 스레드 로컬 스토리지를 생성할 수 있다.
mydata = threading.local()
local 클래스의 여러 인스턴스를 생성하여 서로 다른 변수 집합을 저장할 수 있다. 따라서 이는 [[싱글턴 패턴|싱글턴]]이 아니다.
[[루비 (프로그래밍 언어)|루비]]는 codice_32/codice_33 메서드를 사용하여 스레드 지역 변수를 생성/접근할 수 있다.
Thread.current[:user_id] = 1
[[러스트 (프로그래밍 언어)|러스트]]에서는 러스트 표준 라이브러리에서 제공하는 매크로를 사용하여 스레드 지역 변수를 생성할 수 있다.
use std::cell::RefCell;
thread_local!(static FOO: RefCell&lt;u32&gt; = RefCell::new(1));
FOO.with(|f| {
assert_eq!(*f.borrow(), 1);
*f.borrow_mut() = 2;
// 이 스레드가 이미 스레드 지역 값의 복사본을 2로 변경했음에도 불구하고, 각 스레드는 초기 값인 1로 시작한다.
let t = thread::spawn(move || {
*f.borrow_mut() = 3;
// 스레드가 완료될 때까지 기다리고 패닉 시 종료한다.
t.join().unwrap();
// 자식 스레드가 해당 스레드의 값을 3으로 변경했음에도 불구하고, 원래 스레드는 원래 값인 2를 유지한다.
assert_eq!(*f.borrow(), 2);
[[분류:소프트웨어 디자인 패턴]]
[[분류:변수 (컴퓨터 과학)]]
[[분류:스레드]]
컴퓨터 프로그래밍에서 가드(guard)는 불린식으로, 실행이 해당 분기에서 계속되려면 참으로 평가되어야 한다. 어떤 프로그래밍 언어를 사용하든, 가드 절, 가드 코드 또는 가드 문은 실행 중 오류를 피하기 위해 사용되는 무결성 선행 조건 검사이다.
가드 절이라는 용어는 종종 이름 없는 코딩 관행을 명명된 소프트웨어 디자인 패턴으로 체계화한 켄트 벡에게 귀속되는 소프트웨어 디자인 패턴이다. 이 기술을 사용하는 관행은 적어도 1960년대 초반으로 거슬러 올라간다. 가드 절은 일반적으로 프로시저의 시작 부분에 추가되며, 예외적인 경우를 미리 처리하여 나머지 프로시저를 "보호"한다고 말한다.
전형적인 예는 처리하려는 참조가 널(null)이 아닌지 확인하여 널 포인터 실패를 피하는 것이다.
다른 용도로는 멱등법칙을 위한 불린 필드를 사용하는 것(따라서 후속 호출은 NOP임)이 있다. 예를 들어 폐기 패턴에서와 같다.
public String foo(String username) {
throw new IllegalArgumentException("Username is null.");
중첩이 적은 더 평탄한 코드.
가드는 서브루틴에서 조기 종료를 제공하며, 구조적 프로그래밍에서 흔히 사용되는 편차로, 한 단계의 중첩을 제거하고 더 평탄한 코드를 만든다. `if guard { ... }`를 `if not guard: return; ...`로 대체한다.
가드 절을 사용하는 것은 코드 개선을 위한 리팩토링 기술이 될 수 있다. 일반적으로 중첩이 적을수록 코드가 단순해지고 인지적 부담이 줄어들기 때문에 좋다.
예를 들어, 파이썬에서:
def f_noguard(x):
if isinstance(x, int):
def f_guard(x):
if not isinstance(x, int):
다른 예는 C로 작성되었다.
// 이 함수는 가드 절이 없다
int funcNoGuard(int x) {
if (x &gt;= 0) {
// 가드 절이 있는 동일한 함수
int funcGuard(int x) {
이 용어는 APL, 하스켈, 클린, 얼랭, 오컴, 프로멜라, OCaml, 스위프트, 버전 3.10부터의 파이썬, 그리고 스칼라 프로그래밍 언어에서 특정 의미로 사용된다. 매스매티카에서는 가드를 제약 조건이라고 부른다. 가드는 Guarded Command Language의 기본 개념으로, 정형 기법의 언어이다. 가드는 패턴 매칭을 강화하여 구조가 일치하더라도 패턴을 건너뛸 수 있는 가능성을 제공하는 데 사용될 수 있다. 조건문의 불린식도 일반적으로 가드의 이 정의에 부합하지만 조건이라고 불린다.
다음 하스켈 예시에서 가드는 각 "|"와 "=" 쌍 사이에 나타난다.
f x
| x &gt; 0 = 1
이는 해당 수학적 표기법과 유사하다.
이 경우 가드는 "if" 및 "otherwise" 절에 있다.
여러 가드.
여러 개의 병렬 가드가 있는 경우, 일반적으로 위에서 아래로 시도되며, 먼저 통과한 가드의 분기가 선택된다. 사례 목록의 가드는 일반적으로 병렬이다.
그러나 하스켈의 리스트 캄프리헨션에서는 가드가 직렬이며, 그 중 하나라도 실패하면 리스트 요소는 생성되지 않는다. 이는 별도의 가드들을 논리곱으로 결합하는 것과 동일하지만, 가드들 사이에 다른 리스트 캄프리헨션 절이 있을 수 있다는 점이 다르다.
1963년 CPL에 이미 존재했던 간단한 조건식은 첫 번째 부분식에 가드를 가지고 있으며, 첫 번째 부분식을 사용할 수 없는 경우 사용할 다른 부분식을 가지고 있다. 이를 작성하는 몇 가지 일반적인 방법은 다음과 같다.
(x&gt;0) -&gt; 1/x; 0
x&gt;0 ? 1/x : 0
두 번째 부분식이 더 간단한 조건식일 수 있다면, 마지막으로 통과하기 전에 시도할 더 많은 대안을 제공할 수 있다.
(x&gt;0) -&gt; 1/x; (x&lt;0) -&gt; -1/x; 0
1966년 ISWIM은 의무적인 폴스루(fall-through) 경우가 없는 조건식 형태를 가졌으며, 따라서 가드를 선택 개념과 분리했다. ISWIM의 경우, 대안 중 어느 것도 사용할 수 없으면 값은 미정의로 간주되었고, 이는 값으로 계산되지 않는 것으로 정의되었다.
SASL (1976)의 "소형화된 버전"인 KRC는 "가드"라는 용어를 사용한 최초의 프로그래밍 언어 중 하나였다. 이 언어의 함수 정의는 여러 절을 가질 수 있었고, 적용할 절은 각 절 뒤에 오는 가드를 기반으로 선택되었다.
fac n = 1, n = 0
= n * fac (n-1), n &gt; 0
가드 절의 사용과 "가드 절"이라는 용어는 켄트 벡이 체계화한 1990년대 스몰토크 관행으로 거슬러 올라간다.
1996년, Dyalog APL은 가드가 유일한 제어 구조인 대안적인 순수 함수형 스타일을 채택했다. 다음 APL 예제는 입력 숫자의 패리티를 계산한다.
parity←{
2∣⍵ : 'odd'
'even'
패턴 가드.
패턴에 부착된 가드 외에도, 패턴 가드는 가드의 맥락에서 패턴 매칭을 사용하는 것을 지칭할 수 있다. 효과적으로, 패턴의 일치는 통과를 의미하는 것으로 간주된다. 이 의미는 사이먼 페이튼 존스가 1997년 4월에 A new view of guards라는 제목으로 하스켈에 대한 제안에서 도입되었고, 그 제안의 구현에 사용되었다. 이 기능은 패턴의 가드에 패턴을 사용할 수 있는 기능을 제공한다.
확장 하스켈의 예:
clunky env var1 var2
| Just val1 &lt;- lookup env var1
, Just val2 &lt;- lookup env var2
= val1 + val2
-- ...other equations for clunky...
이는 다음과 같이 읽힌다: "환경과 두 변수에 대한 클렁키는, 환경에서 변수 조회가 값을 생성하는 경우, 값들의 합이다. ..." 리스트 캄프리헨션에서처럼 가드는 직렬이며, 그 중 하나라도 실패하면 분기는 취해지지 않는다.
컴퓨터 프로그래밍에서 심(shim)은 투명하게 API 호출을 가로채고 전달된 인수를 변경하거나, 작업을 직접 처리하거나, 다른 곳으로 작업을 리디렉션하는 라이브러리이다. 심은 최신 환경에서 이전 API를 지원하거나, 이전 환경에서 새로운 API를 지원하는 데 사용될 수 있다. 심은 또한 개발된 소프트웨어 플랫폼과 다른 소프트웨어 플랫폼에서 프로그램을 실행하는 데 사용될 수도 있다.
이전 API용 심은 일반적으로 API의 동작이 변경되어 이전 기능에 여전히 의존하는 이전 응용 프로그램에 호환성 문제가 발생하는 경우에 만들어진다. 이러한 경우, 이전 API는 새로운 코드 위에 얇은 호환성 계층을 통해 계속 지원될 수 있다. 새로운 API용 심은 "이전 환경의 수단만을 사용하여 새로운 API를 이전 환경으로 가져오는 라이브러리"로 정의된다.
에리히 감마(Erich Gamma)는 스위스의 컴퓨터 과학자이자 소프트웨어 공학 교과서인 디자인 패턴(Design Patterns: Elements of Reusable Object-Oriented Software)의 네 명의 공동 저자("갱 오브 포"로 불림) 중 한 명이다.
감마는 켄트 벡과 함께 JUnit 소프트웨어 테스트 프레임워크를 공동으로 작성하여 테스트 주도 개발을 창출하는 데 기여했으며, 전체 소프트웨어 산업에 영향을 미쳤다. 이클립스 플랫폼의 자바 개발 도구(JDT)의 개발팀 리더였으며 IBM 래셔널 재즈 프로젝트에서 일했다.
2011년 그는 마이크로소프트 비주얼 스튜디오 팀에 합류하여 스위스 취리히에 있는 개발 연구소를 이끌고 있다. 이 연구소는 애저 데브옵스 서비스(Azure DevOps Services, 구 Visual Studio Team Services 및 Visual Studio Online), 비주얼 스튜디오 코드, Azure Mobile Services, Azure Web Sites, Office 365 개발 도구와 같은 제품에서 볼 수 있는 브라우저 기반 개발용 "모나코" 구성 요소 제품군을 개발했다.
UCSD 파스칼(UCSD Pascal)은 이식성이 뛰어나고 기계 독립성이 높은 운영체제인 UCSD p-시스템에서 실행되는 파스칼 프로그래밍 언어 시스템이다. UCSD 파스칼은 1977년에 처음 출시되었으며, 캘리포니아 대학교 샌디에이고(UCSD)에서 개발되었다.
p-시스템.
1977년, 캘리포니아 대학교 샌디에이고(UCSD) 정보 시스템 연구소는 당시 사용 가능한 모든 마이크로컴퓨터와 캠퍼스의 DEC 미니컴퓨터인 PDP-11에서 실행될 수 있는 공통 환경을 학생들에게 제공하기 위해 UCSD 파스칼을 개발했다. 이 운영체제는 UCSD p-시스템으로 알려지게 되었다.
IBM은 오리지널 IBM PC를 위해 UCSD p-시스템, CP/M-86, IBM PC DOS의 세 가지 운영체제를 제공했다. 벤더인 소프텍 마이크로시스템즈는 IBM PC 출시 당시 20개의 CPU용 가상 머신을 갖춘 p-시스템의 애플리케이션 이식성을 강조했다. 사용자들은 p-시스템을 실행하는 미래 컴퓨터에서 구매한 애플리케이션을 사용할 수 있을 것이라고 예측했으며, 광고에서는 이를 "범용 운영체제"라고 불렀다.
PC Magazine은 IBM PC의 UCSD p-시스템을 비난하며, 해당 언어로 작성된 Context MBA 리뷰에서 "좋은 코드를 생성하지 못한다"고 언급했다. p-시스템은 애플리케이션 부족과 다른 선택지보다 비싼 가격 때문에 IBM PC에서 잘 팔리지 않았다. 이전에 IBM은 IBM 디스플레이라이터에 UCSD p-시스템을 옵션으로 제공했다. 디스플레이라이터는 8086 기반의 전용 워드 프로세싱 기계였다. (디스플레이라이터의 기본 운영체제는 완전히 내부적으로 개발되었고 최종 사용자 프로그래밍을 위해 공개되지 않았다.)
표준 파스칼에 대한 주목할 만한 확장 기능으로는 별도 컴파일 가능한 단위와 스트링 유형이 있다. 일부 내장 함수는 문자열 처리(예: 특정 검색 패턴을 위한 배열 스캔)를 가속화하기 위해 제공되었고, 다른 언어 확장은 UCSD p-시스템이 자체 컴파일되고 자체 호스팅되도록 허용하기 위해 제공되었다.
UCSD 파스칼은 p-코드 머신 아키텍처를 기반으로 했다. 이 초기 가상 머신에 대한 기여는 p-코드를 컴파일러 중간 언어로서의 뿌리에서 벗어나 완전한 실행 환경으로 확장한 것이었다. UCSD 파스칼 p-머신은 16비트로 제한된 주소 지정(64KB 메모리만)을 가진 새로운 소형 마이크로컴퓨터에 최적화되었다. 제임스 고슬링은 UCSD 파스칼을 자바 가상 머신 설계에 대한 주요 영향(그리고 스몰토크 가상 머신과 함께)으로 언급한다.
UCSD p-시스템은 p-머신(또는 가상 머신, 많은 사용자들이 OS처럼 "파스칼-머신"이라고 부르기 시작했지만 UCSD 문서에서는 항상 "가상 머신"을 사용했다)이라고 불리는 가상 머신을 정의하여 기계 독립성을 달성했으며, 자체 명령어 집합인 p-코드(또는 가상 코드)를 가졌다. 니클라우스 비르트의 제자인 Urs Ammann은 원래 그의 박사 학위 논문에서 p-코드를 제시했으며, 여기서 UCSD 구현은 취리히 파스칼-P 구현에서 파생되었다. UCSD 구현은 취리히 구현을 "바이트 지향적"으로 변경했다. UCSD p-코드는 파스칼 프로그래밍 언어 실행에 최적화되었다. 각 하드웨어 플랫폼은 전체 p-시스템과 모든 도구를 실행하기 위해 p-코드 인터프리터 프로그램만 작성하면 되었다. 나중에 나온 버전에는 p-코드 기반으로 컴파일되는 추가 언어도 포함되었다. 예를 들어, 애플 컴퓨터는 애플 버전의 p-시스템에서 실행되는 p-코드를 생성하는 포트란 컴파일러(실리콘 밸리 소프트웨어, 서니베일 캘리포니아에서 작성)를 제공했다. 나중에는 텔레소프트(샌디에고에도 위치)가 p-코드를 사용하여 모토로라 68000, System/370, 파스칼 마이크로엔진을 포함한 여러 하드웨어 플랫폼에서 실행될 수 있는 초기 에이다 개발 환경을 제공했다.
UCSD p-시스템은 나중에 나온 자바 플랫폼과 일부 개념을 공유한다. 둘 다 운영체제와 하드웨어의 차이를 숨기기 위해 가상 머신을 사용하며, 해당 가상 머신용으로 작성된 프로그램을 사용하여 크로스 플랫폼 지원을 제공한다. 마찬가지로 두 시스템 모두 가상 머신을 대상 컴퓨터의 완전한 운영체제로 사용하거나 다른 운영체제 아래의 "상자"에서 실행할 수 있도록 허용한다.
UCSD 파스칼 컴파일러는 이식 가능한 운영체제인 p-시스템의 일부로 배포되었다.
UCSD p-시스템은 1974년경 UCSD의 케네스 보울스의 아이디어에서 시작되었다. 그는 당시 등장하던 수많은 새로운 컴퓨팅 플랫폼들이 새로운 프로그래밍 언어가 수용되는 것을 어렵게 만들 것이라고 믿었다. 그는 UCSD 파스칼을 취리히의 휴대용 컴파일러인 파스칼-P2 릴리스를 기반으로 했다. 특히 그는 파스칼을 프로그래밍 교육 언어로 관심을 가졌다. UCSD는 원래 파스칼에 중요한 개선 사항인 가변 길이 문자열과 독립적으로 컴파일된 코드의 "단위"(당시 진화 중이던 에이다 (프로그래밍 언어)에 포함된 아이디어) 두 가지 기능을 도입했다. 니클라우스 비르트는 p-시스템, 특히 UCSD 파스칼이 파스칼을 대중화하는 데 기여했다고 평가한다. 터보 파스칼이 출시되기 전까지는 UCSD 버전이 파스칼 사용자들 사이에서 선두 자리를 유지했다.
UCSD 파스칼의 파스칼 방언은 파스칼-P2에서 구현된 파스칼의 하위 집합에서 유래했는데, 이는 언어의 완전한 구현을 목표로 한 것이 아니라 파스칼 컴파일러의 부트스트랩 키트로서의 기능을 충족시키기 위해 "자체 컴파일할 수 있는 최소 하위 집합"으로 설계되었다. UCSD는 BASIC의 문자열과 몇 가지 다른 구현 의존적 기능을 추가했다. UCSD 파스칼은 나중에 전체 파스칼 언어의 다른 많은 기능을 얻었지만, 파스칼-P2 하위 집합은 다른 방언, 특히 UCSD 방언의 많은 부분을 복사한 볼랜드 파스칼에도 계속 존재했다.
UCSD p-코드 엔진은 네 가지 버전이 있었으며, 각 버전은 p-시스템과 UCSD 파스칼의 여러 개정판을 포함했다. p-코드 엔진(즉, p-머신)의 개정은 p-코드 언어의 변경을 의미했으며, 따라서 컴파일된 코드는 다른 p-머신 버전 간에 이식할 수 없다. 각 개정은 로마 숫자로 표시되었고, 운영체제 개정은 p-코드 로마 숫자 뒤에 오는 "점" 숫자로 열거되었다. 예를 들어, II.3은 두 번째 p-머신 개정판에서 실행되는 p-시스템의 세 번째 개정판을 나타냈다.
버전 I.
원래 버전으로, 캘리포니아 대학교 샌디에이고 외부에는 공식적으로 배포되지 않았다. 그러나 버전 I.3과 I.5의 파스칼 소스는 관심 있는 사용자들 사이에서 자유롭게 교환되었다. 특히 패치 개정판 I.5a는 가장 안정적인 버전 중 하나로 알려져 있었다.
버전 II.
널리 배포되었고 많은 초기 마이크로컴퓨터에서 사용 가능했다. 수많은 버전에는 궁극적으로 애플 II용 애플 파스칼, DEC PDP-11, 인텔 8080, 자일로그 Z80, MOS 6502 기반 머신, 모토로라 68000 및 IBM PC용(PC용 버전 II는 하나의 64K 코드 세그먼트와 하나의 64K 스택/힙 데이터 세그먼트로 제한되었으며, 버전 IV는 코드 세그먼트 제한을 제거했지만 훨씬 비쌌다.
이 시대의 프로젝트 멤버로는 케네스 L 보울스 박사, 마크 앨런, 리처드 글리브스, 리처드 카프만, 피트 로렌스, 조엘 맥코맥, 마크 오버가드, 키스 실링턴, 로저 섬너, 존 반 잔트 등이 있다.
버전 III.
웨스턴 디지털이 자사의 파스칼 마이크로엔진 마이크로컴퓨터에서 실행되도록 맞춤 제작한 버전. 처음으로 병렬 프로세스 지원을 포함했다.
버전 IV.
소프텍에서 개발 및 판매한 상업용 버전. 버전 II를 기반으로 했으며, 버전 III의 변경 사항은 포함하지 않았다. 가격 정책, p-코드 인터프리터로 인한 성능 문제, 그리고 (종종 그 위에서 실행되는) 기본 운영체제와의 경쟁으로 인해 잘 팔리지 않았다. 소프텍이 제품을 포기한 후, p-시스템 사용자 및 팬들로 구성된 비교적 작은 회사인 피칸 시스템즈가 제품을 인수했다. 피칸의 합리적인 가격 정책 덕분에 판매가 다소 회복되었지만, p-시스템과 UCSD 파스칼은 점차 기본 운영체제와 컴파일러에 시장을 잃었다. p-코드 카드, 코모도어 CBM 8096, Sage IV, HP 9000, 6502 보조 프로세서가 장착된 BBC 마이크로가 장착된 TI-99/4A에서 사용 가능했다.
추가 사용.
코르부스 시스템즈 컴퓨터는 모든 사용자 소프트웨어에 UCSD 파스칼을 사용했다. 컨스텔레이션 OS의 "혁신적인 개념"은 파스칼(인터프리터 방식 또는 컴파일 방식)을 실행하고 모든 공통 소프트웨어를 매뉴얼에 포함하여 사용자가 필요에 따라 수정할 수 있도록 하는 것이었다.
Cooperative Linux는 coLinux로 줄여 부르며, 마이크로소프트 윈도우와 리눅스 커널이 동일한 기계에서 동시에 병렬로 실행될 수 있도록 하는 소프트웨어이다.
Cooperative Linux는 협력 가상 머신(CVM)의 개념을 활용한다. 기존의 가상 머신과 달리 CVM은 호스트 OS에 이미 존재하는 자원을 공유한다. 기존 VM 호스트에서는 모든 (게스트) OS에 대해 자원이 가상화된다. CVM은 두 OS 모두에게 호스트 머신에 대한 완전한 제어권을 부여하는 반면, 기존 VM은 모든 게스트 OS를 실제 머신에 접근할 수 없는 비특권 상태로 설정한다.
"협력적"이라는 용어는 병렬로 작동하는 두 엔티티를 설명하는 데 사용된다. 실제로 Cooperative Linux는 두 개의 다른 운영 체제 커널을 두 개의 큰 코루틴으로 변환한다. 각 커널은 자체적인 완전한 CPU 컨텍스트와 주소 공간을 가지며, 각 커널은 파트너에게 언제 제어권을 돌려줄지 결정한다.
그러나 두 커널이 이론적으로 실제 하드웨어에 대한 완전한 접근 권한을 가지고 있지만, 최신 PC 하드웨어는 두 개의 다른 운영 체제에 의해 동시에 제어되도록 설계되지 않았다. 따라서 호스트 커널은 실제 하드웨어 제어권을 유지하고 게스트 커널은 호스트와 통신하고 게스트 OS에 다양한 중요한 장치를 제공하는 특수 드라이버를 포함한다. 호스트는 Cooperative Linux 이식 가능한 드라이버가 CPL0 모드 (링 0)에서 실행되고 메모리를 할당할 수 있도록 기본 프리미티브를 내보내는 모든 OS 커널이 될 수 있다.
댄 알로니는 사용자 모드 리눅스와의 유사한 작업을 기반으로 한 연구 프로젝트로 Cooperative Linux 개발을 시작했다. 그는 2004년 1월 25일에 개발을 발표했다. 2004년 7월에 그는 리눅스 심포지엄에서 논문을 발표했다. 소스는 GNU 일반 공중 사용 허가서로 출시되었다. 그 이후로 다른 개발자들이 소프트웨어에 다양한 패치와 추가 기능을 기여했다.
Cooperative Linux는 일반적으로 게스트 OS를 호스트 커널보다 낮은 권한 모드로 실행하고, 모든 자원을 호스트 커널에 위임하는 완전한 X86 가상화와는 상당히 다르다. 이와 대조적으로 Cooperative Linux는 특별히 수정된 리눅스 커널을 실행하는데, 이 커널은 NT 커널과 자원을 공유하고 경쟁 상태를 유발하지 않는다는 점에서 협력적이다.
Cooperative Linux 패치의 대부분의 변경 사항은 i386 트리에 있다. 이는 이 글을 쓰는 시점에서 Cooperative가 지원하는 유일한 아키텍처이다. 다른 변경 사항은 주로 가상 드라이버의 추가이다: cobd(블록 장치), conet(네트워크), cocon(콘솔). i386 트리의 대부분 변경 사항은 초기화 및 설정 코드와 관련이 있다. Cooperative Linux 커널 설계의 목표는 독립형 i386 커널에 최대한 가깝게 유지하는 것이므로, 모든 변경 사항은 가능한 한 지역화되고 최소화된다.
coLinux 패키지는 리눅스 커널의 포트와 가상 네트워크 장치를 설치하며, 윈도우 2000 또는 윈도우 XP와 같은 윈도우 운영 체제 버전에서 동시에 실행될 수 있다. VM웨어와 같은 가상 머신을 사용하지 않는다.
데비안, 우분투, 페도라, 젠투는 coLinux 사용자들에게 특히 인기가 많다.
가상 하드웨어의 다소 특이한 구조 때문에 coLinux에서 리눅스 배포판을 설치하는 것은 일반적으로 어렵다. 따라서 대부분의 경우 사용자는 실제 파티션에 있는 기존 리눅스 설치를 사용하거나, 프로젝트에서 배포하는 미리 만들어진 파일 시스템 이미지를 사용한다. 파일 시스템 이미지는 일반 리눅스 시스템의 이미지를 찍거나, 이상한 하드웨어에서 설치 프로그램을 실행할 방법을 찾거나, 패키지 관리자를 사용하여 수동으로 설치를 구축하거나, 단순히 yum 및 apt와 같은 도구를 사용하여 기존 이미지를 업그레이드하는 등 다양한 방법으로 만들어진다. 최신 파일 시스템 이미지를 얻는 더 쉬운 방법은 QEMU를 사용하여 리눅스를 설치하고 coLinux 위키에 설명된 대로 처음 63개의 512바이트 블록을 제거하여 이미지를 "변환"하는 것이다.
coLinux는 기본 그래픽 하드웨어에 접근할 수 없으므로 X 윈도 또는 X 서버는 coLinux에서 직접 실행되지 않지만, 시그윈/X 또는 Xming과 같은 X 서버를 윈도우에 설치하여 KDE 또는 그놈과 거의 모든 다른 리눅스 응용 프로그램 및 배포판을 사용할 수 있다. 이 모든 문제는 우분투 기반의 andLinux 또는 슬랙웨어 기반의 TopologiLinux와 같은 coLinux 기반 배포판을 사용함으로써 해결된다.
전용 배포판.
몇몇 배포판은 coLinux와 함께 작동하도록 특별히 제작되었다.
히타치 H8은 르네사스 일렉트로닉스가 제조한 대규모 8비트, 16비트, 32비트 마이크로컨트롤러 제품군으로, 1990년대 초 히타치 반도체에서 시작되었다. 원래의 설계인 H8/300은 16비트 레지스터와 ALU를 갖춘 8비트 프로세서로, 일부 16비트 연산을 허용했다. 두 가지 업그레이드 버전이 출시되었는데, H8/300L은 명령어를 확장하여 완전한 16비트 머신이 되면서 저비용에 최적화되었고, H8/300H는 레지스터를 더욱 확장하여 32비트 연산을 허용하고 저전력/고성능 역할에 최적화되었다. 많은 변형이 존재한다.
전체 라인은 2003년 르네사스에 매각되었다. 르네사스는 2023년 현재까지도 이 디자인을 기존 고객에게만 판매하고 있다. 르네사스 사용자 커뮤니티 게시판의 한 관리자는 2011년에 H8 기반 제품의 추가 개발 계획이 없다고 언급했다. H8은 리눅스 커널 버전 4.2부터 지원되었지만, 버전 5.19에서 지원이 제거되었다.
더 높은 성능이 필요한 경우, 히타치는 슈퍼H 32비트 RISC 유사 마이크로컨트롤러 제품군을 출시했으며, 이는 H8을 상당 부분 대체했다.
하위 제품군에는 8/16비트 H8/300 및 H8/500, 16/32비트 H8/300H 및 H8S, 그리고 32비트 H8SX 시리즈가 있으며, 각각 속도, 타이머, 인터럽트, 직렬 포트와 같은 내장 주변기기 선택, ROM, 플래시 메모리 및 RAM의 양에 따라 수십 가지의 다양한 변형이 존재한다. 내장 ROM과 플래시 메모리는 일반적으로 16 KB에서 1024 KB까지, RAM은 512 B에서 512 KB까지 다양하다.
H8의 기본 아키텍처는 DEC PDP-11 아키텍처를 본떠 만들어졌으며, 8개의 16비트 레지스터(H8/300H 및 H8S는 추가로 8개의 16비트 레지스터 뱅크를 가지고 있음)와 다양한 주소 지정 방식을 특징으로 한다. 그러나 PDP-11과 달리 H8 아키텍처는 빅 엔디언 바이트 순서를 사용한다.
H8/300H와 H8S는 모두 8개의 32비트 레지스터를 가지고 있으며, 각 레지스터는 하나의 32비트 레지스터, 두 개의 16비트 레지스터, 또는 두 개의 8비트 레지스터로 취급될 수 있으며, H8S는 내부 32비트 구성을 가지고 있다. 여러 회사에서 H8 제품군용 컴파일러를 제공하며, GCC 포트 전체와 시뮬레이터도 포함되어 있다. 다양한 하드웨어 에뮬레이터도 사용할 수 있다.
이 제품군은 H8SX 32비트 컨트롤러로 이어지고 있다.
H8S는 디지털 카메라, 시비코 휴대용 컴퓨터, 일부 씽크패드 노트북, 프린터 컨트롤러, 스마트카드, 체스 컴퓨터, 야마하 FS1R과 같은 음악 신시사이저, 롤랜드 SC-55 및 Roland JV880 그리고 다양한 자동차 서브시스템에서 발견될 수 있다. 고급 로봇 장난감/교육 도구인 레고 마인드스톰 RCX는 H8/300을 사용한다. H8/3002는 1990년대 후반 남코가 제작한 다양한 게임, 특히 System 12 아키텍처를 사용하는 게임과 야마하의 DB50XG 및 DB60XG 도터보드와 SW60XG ISA 버스 사운드 카드에서 사운드 프로세서로 사용되었다.
H8/500은 노키아 2110 전화기에도 사용되었다.
BASIC 스탬프(BASIC Stamp)는 ROM에 작은 특수 베이직 인터프리터(PBASIC)가 내장된 마이크로컨트롤러이다. 패러렐스에서 만들었으며 1990년대 초부터 전자제품 애호가들에게 인기가 많았다.
BASIC 스탬프 2는 24핀 DIP 칩 형태를 띠고 있지만, 사실은 마이크로프로세서 시스템의 필수 요소를 포함하는 작은 인쇄 회로 기판(PCB)이다.
그 결과 애호가는 9V 배터리를 BASIC 스탬프에 연결하여 완전한 시스템을 가질 수 있다. 개인용 컴퓨터와의 직렬 통신은 프로그래머가 소프트웨어를 BASIC 스탬프에 다운로드할 수 있게 하며, 이는 온보드 비휘발성 메모리 장치에 저장된다. 즉, 스탬프의 전원이 제거되어도 지워지거나 다시 프로그래밍될 때까지 프로그램이 유지된다. 전원이 다시 연결되면 스탬프는 즉시 슬롯 0(0~7번 중 0번)의 프로그램을 실행하기 시작한다.
BASIC 스탬프는 베이직 언어의 변형인 PBASIC으로 프로그래밍된다. PBASIC은 PWM, 직렬 통신, I²C 및 1-Wire 통신, 일반 LCD 드라이버 회로와의 통신, 취미 서보 펄스 트레인, 유사 정현파 주파수, 아날로그 값을 감지하는 데 사용할 수 있는 RC 회로 타이밍 기능 등 일반적인 마이크로컨트롤러 기능을 통합한다.
Windows의 통합 개발 환경(IDE)인 '스탬프 에디터'에서 프로그램이 작성되면 통사론을 확인하고 토큰화하여 직렬/USB 미니-B 케이블을 통해 칩으로 전송되어 실행된다.
현재 인터프리터는 네 가지 변형이 있다.
BS2 하위 변형은 원래 BS2 모델에 비해 더 많은 메모리, 더 높은 실행 속도, 추가적인 특수 PBASIC 명령, 추가 I/O 핀 등을 특징으로 한다. BS1과 BS2는 PIC를 사용하는 반면, 나머지 BASIC 스탬프 2 변형은 패러렐스 SX 프로세서를 사용한다.
세 번째 변형은 재블린 스탬프이다. 이 모듈은 패러렐스의 PBASIC 대신 썬 마이크로시스템즈의 자바 프로그래밍 언어의 하위 집합을 사용한다. 네트워킹 기능은 포함하지 않는다.
네 번째 변형은 스핀 스탬프이다. 이 모듈은 패러렐스 프로펠러를 기반으로 하므로 PBASIC 대신 SPIN 프로그래밍 언어를 사용한다.
현재 여러 회사에서 더 빠른 실행, 아날로그-디지털 변환기 및 백그라운드에서 실행될 수 있는 하드웨어 기반 PWM과 같은 추가 기능을 갖춘 BASIC 스탬프 "클론"을 만들고 있다.
패러렐스 프로펠러는 BASIC 스탬프와 유사한 기능을 제공하는 소프트웨어 라이브러리를 점차 축적하고 있다. 그러나 어떤 PBASIC 기능에 현재 스핀에 해당하는 기능이 있는지에 대한 통일된 목록은 없다.
ESP32는 와이파이 및 블루투스 기능을 모두 통합한 저비용, 에너지 효율적인 마이크로컨트롤러 제품군이다. 이 칩들은 듀얼 코어 및 싱글 코어 변형으로 제공되는 텐실리카 Xtensa LX6 마이크로프로세서, Xtensa LX7 듀얼 코어 프로세서 또는 단일 코어 RISC-V 마이크로프로세서를 포함한 다양한 처리 옵션을 특징으로 한다. 또한 ESP32는 내장 안테나 스위치, RF 발룬, 전력 증폭기, 저잡음 수신기, 필터 및 전력 관리 모듈과 같은 무선 데이터 통신에 필수적인 구성 요소를 통합한다.
일반적으로 ESP32는 특정 장치용 인쇄 회로 기판에 내장되거나 다양한 GPIO 핀 및 커넥터를 포함하는 개발 키트의 일부로 제공되며, 구성은 모델 및 제조업체에 따라 달라진다. ESP32는 에스프레시프 시스템즈에서 설계했으며 TSMC의 40 nm 공정을 사용하여 제조한다. 이는 ESP8266 마이크로컨트롤러의 후속 제품이다.
ESP32의 특징은 다음과 같다.
ESP32-xx 제품군.
오리지널 ESP32가 출시된 이래로 여러 변형이 소개되고 발표되었다. 이들은 ESP32 마이크로컨트롤러 제품군을 구성한다. 이 칩들은 다른 중앙 처리 장치와 기능을 가지고 있지만, 모두 동일한 SDK를 공유하고 있으며 대부분 코드 호환성이 있다. 또한 오리지널 ESP32는 수정되었다 (예: ESP32 ECO V3 참조).
QFN 패키지 칩 및 모듈.
ESP32는 49개의 패드를 가진 다양한 크기의 QFN 패키지에 담겨 있다. 구체적으로는 측면에 48개의 연결 패드와 하단에 하나의 큰 열 패드 (접지 연결)가 있다.
ESP32 시스템 온 칩 집적회로는 6 mm × 6 mm 및 5 mm × 5 mm 크기의 QFN 패키지에 담겨 있다.
2020년, ESP32-D0WDQ6 및 ESP32-D0WD 칩은 V3 버전 (ESP32 ECO V3)이 출시되어 일부 버그를 수정하고 이전 버전보다 개선되었다.
ESP32 PICO system in package 모듈은 ESP32 실리콘 칩, 크리스탈 발진기, 플래시 메모리 칩, 필터 커패시터 및 RF 매칭 링크를 단일 7 mm × 7 mm 크기의 QFN 패키지에 결합한다.
처음 출시된 PICO는 ESP32-PICO-D4로, 240MHz의 듀얼 CPU, 4MiB 내장 플래시, 40MHz 발진기 및 34개의 GPIO를 갖추고 있다.
이후 2020년에 ESP32 ECO V3 웨이퍼를 기반으로 하는 ESP32-PICO-V3 및 ESP32-PICO-V3-02 모듈이 출시되었다.
2022년에는 USB OTG 및 내부 PSRAM이 포함된 ESP32-S3-PICO-1 모듈이 출시되었다.
표면 실장 모듈 보드.
ESP32 기반 표면 실장 인쇄 회로 기판 모듈은 ESP32 SoC를 직접 포함하며 다른 회로 기판에 쉽게 통합할 수 있도록 설계되었다. 아래 나열된 모듈의 PCB 트레이스 안테나에는 구불구불한 역F형 안테나 디자인이 사용된다. 플래시 메모리 외에도 일부 모듈에는 슈도정적 RAM (pSRAM)이 포함된다.
개발 및 기타 보드.
개발 및 브레이크아웃 보드는 배선을 확장하고 기능을 추가할 수 있으며, 종종 ESP32 모듈 보드를 기반으로 하여 개발 목적으로, 특히 브레드보드와 함께 사용하기 쉽도록 만들어진다.
† ESP32 SoC가 개발 보드에 직접 통합됨; 모듈 보드는 사용되지 않음.
ESP32 프로그래밍에 사용되는 프로그래밍 언어, 프레임워크, 플랫폼 및 환경:
수용 및 사용.
ESP32의 상업적, 산업적, 학문적 사용:
ESP32의 문서화되지 않은 HCI 명령어.
2025년 3월, Tarlogic Security의 연구원들은 ESP32 블루투스 펌웨어에서 문서화되지 않은 HCI(Host Controller Interface) 명령어를 발견했으며, 이는 그 기능과 잠재적 영향에 대한 논의를 촉발했다. 이 발견은 2025년 3월 6일 RootedCON 컨퍼런스에서 Tarlogic Security 팀에 의해 발표되었다.
식별된 명령어(예: Write Memory (0xFC02))는 주로 디버깅 및 테스트 목적으로 사용되는 공급업체별 HCI 명령어이다. 이러한 유형의 명령어는 개발 및 문제 해결에 도움을 주기 위해 블루투스 컨트롤러 구현에서 흔히 사용된다. 이들은 표준 HCI 명령어 세트의 일부가 아니며 일반적으로 통제된 환경에서 사용된다. 처음에는 "백도어"로 묘사되었지만, 추가 설명에서는 "문서화되지 않은 디버깅 기능"으로 분류되었다. 이 명령어는 표준 블루투스 연결을 통해 원격으로 접근할 수 없지만, 개체가 장치에 물리적으로 접근하거나 HCI-UART 구성으로 작동하는 경우 상호 작용할 수 있다.
에스프레시프 시스템즈는 이 명령어에 대해 명확하게 설명하며, 이들은 디버깅을 위한 것이며 정상 작동 조건에서는 보안 위험을 초래하지 않는다고 밝혔다. 회사는 이 명령어들이 원격으로 트리거될 수 없으며 표준 블루투스 작업에서 사용되지 않는다고 강조했다. 이 명령어들은 ESP32 칩에만 존재하며, ESP32-C, ESP32-S, ESP32-H 시리즈에는 포함되어 있지 않다. 보안 커뮤니티에서 제기된 우려를 해소하기 위해 에스프레시프는 향후 ESP-IDF 버전에 이 디버깅 명령어에 대한 접근을 제한하고 공급업체별 HCI 명령어에 대한 문서화를 개선하는 업데이트를 포함할 것이라고 발표했다. 이러한 조치는 투명성을 높이고 개발자들이 사용 가능한 기능에 대해 잘 알 수 있도록 하는 것을 목표로 한다.
ESP8266은 중국 상하이의 Espressif Systems에서 생산된 저비용 와이파이마이크로칩으로, 내장된 TCP/IP 네트워킹 소프트웨어와 마이크로컨트롤러 기능을 갖추고 있다.
이 칩은 2014년 8월, 타사 제조업체 Ai-Thinker가 만든 ESP-01 모듈을 통해 영어권 메이커 커뮤니티에서 인기를 얻었다. 이 작은 모듈은 마이크로컨트롤러가 와이파이 네트워크에 연결하고 헤이즈 스타일 명령을 사용하여 간단한 TCP/IP 연결을 할 수 있도록 한다. 그러나 처음에는 이 칩과 칩이 수용하는 명령에 대한 영어 문서가 거의 없었다. 매우 낮은 가격과 모듈에 외부 부품이 거의 없다는 사실은 대량 생산 시 매우 저렴해질 수 있음을 시사하며, 많은 해커들이 모듈, 칩 및 소프트웨어를 탐구하고 중국어 문서를 번역하도록 이끌었다.
ESP8285는 1 MiB 플래시 메모리가 내장된 유사한 칩으로, 와이파이를 통해 연결할 수 있는 단일 칩 장치를 설계할 수 있도록 한다.
이 마이크로컨트롤러 칩들은 ESP32 제품군에 의해 계승되었다.
ESP-01 핀 배열.
일반적인 ESP-01 모듈의 핀 배열은 다음과 같다:
SDK.
2014년 10월, Espressif Systems는 칩을 직접 프로그래밍할 수 있는 SDK를 출시하여 별도의 마이크로컨트롤러가 필요 없게 되었다. 그 이후로 Espressif는 여러 공식 SDK 릴리스를 발표했으며, Espressif는 두 가지 버전의 SDK를 유지하고 있다. 하나는 FreeRTOS 기반이고 다른 하나는 콜백 기반이다.
Espressif의 공식 SDK 외의 대안으로는 Max Filippov가 유지 관리하는 GCC 툴체인 기반의 오픈 소스 ESP-Open-SDK가 있다. 또 다른 대안은 Mikhail Grigorev의 "비공식 개발 키트"이다.
주로 오픈 소스인 다른 SDK는 다음과 같다.
Espressif 모듈.
다음은 Espressif에서 만든 ESP8266 기반 모듈 시리즈이다.
위 표(및 이어지는 두 표)에서 "활성 핀"은 외부 장치를 ESP8266 MCU에 연결할 수 있는 GPIO 및 ADC 핀을 포함한다. "피치"는 ESP8266 모듈의 핀 간 간격으로, 장치를 브레드보드에 사용할 경우 알아야 할 중요한 정보다. "폼 팩터"는 "2 × 9 DIL"과 같이 모듈 패키징을 설명하는데, 이는 DIP IC의 핀처럼 "듀얼 인 라인"으로 배열된 9개 핀의 두 줄을 의미한다. 많은 ESP-xx 모듈에는 작은 온보드 LED가 포함되어 있어 깜빡이도록 프로그래밍하여 활동을 나타낼 수 있다. ESP-xx 보드에는 트레이스 안테나, 온보드 세라믹 안테나, 외부 Wi-Fi 안테나를 연결할 수 있는 외부 커넥터 등 여러 안테나 옵션이 있다. Wi-Fi 통신은 많은 RFI(무선 주파수 간섭)를 발생시키므로, FCC와 같은 정부 기관은 다른 장치와의 간섭을 최소화하기 위해 차폐된 전자 장치를 선호한다. 일부 ESP-xx 모듈은 FCC 승인 스탬프가 찍힌 금속 상자에 들어 있다. 선진국 시장에서는 FCC 승인 및 차폐된 Wi-Fi 장치가 요구될 가능성이 높다.
Ai-Thinker 모듈.
다음은 타사 제조업체 Ai-Thinker가 ESP8266으로 만든 첫 번째 모듈 시리즈이며 가장 널리 사용된다. 이들은 총칭하여 "ESP-xx 모듈"이라고 불린다. 작동 가능한 개발 시스템을 구축하려면 추가 구성 요소, 특히 직렬 TTL-USB 어댑터(때로는 USB-UART 브리지라고도 함)와 외부 3.3V 전원 공급 장치가 필요하다. 초보 ESP8266 개발자는 USB-UART 브리지와 3.3V 전압 레귤레이터가 보드에 내장된 마이크로 USB 커넥터가 포함된 NodeMCU와 같은 대형 ESP8266 Wi-Fi 개발 보드를 고려하는 것이 좋다. 프로젝트 개발이 완료되면 이러한 구성 요소는 필요하지 않으며, 이러한 저렴한 ESP-xx 모듈은 생산 실행을 위한 저전력, 소형 풋프린트 옵션이다.
참고 열에서 플래시 메모리 크기는 주어진 모듈과 표의 모든 하위 모듈에 적용된다. 단일 모듈에 적용되는 예외는 괄호 안에 표시된다.
기타 보드.
이 보드들이 초기 ESP-xx 모듈보다 인기가 있는 이유는 온보드 USB-UART 브리지(Silicon Labs의 CP2102 또는 WCH CH340G 등)와 마이크로 USB 커넥터가 포함되어 있기 때문이다. 이들은 3.3V 레귤레이터와 결합되어 보드에 전원을 공급하고 호스트(소프트웨어 개발) 컴퓨터, 즉 콘솔과 연결성을 제공하여 쉬운 개발 플랫폼이 된다. 초기 ESP-xx 모듈에서는 이 두 가지 항목(USB-직렬 어댑터 및 레귤레이터)을 별도로 구매하여 ESP-xx 회로에 연결해야 했다. NodeMCU와 같은 최신 ESP8266 보드는 작업하기 더 쉽고 더 많은 GPIO 핀을 제공한다. 여기에 나열된 대부분의 보드는 ESP-12E 모듈을 기반으로 하지만, 새로운 모듈이 몇 달마다 계속해서 출시되고 있는 것처럼 보인다.
ESP32-C3.
2020년, Espressif는 ESP8266과 핀 호환이 되는 새로운 칩인 ESP32-C3를 발표했다. 이 칩은 최대 160 MHz의 클럭 속도를 가진 단일 코어 RISC-V 32비트 CPU를 기반으로 하며, 400 KiB의 SRAM과 384 KiB의 ROM 저장 공간이 내장되어 있다.
MCS-48 마이크로컨트롤러 시리즈는 인텔의 첫 번째 마이크로컨트롤러로, 1976년에 처음 출시되었다. 초기 구성원으로는 8048, 8035, 8748이 있다. 8048은 이 제품군에서 가장 유명한 구성원이라고 할 수 있다. 처음에는 이 제품군이 NMOS (n형 금속 산화물 반도체) 기술을 사용하여 생산되었다. 1980년대 초에는 CMOS 기술로도 제공되었다. 이 기술을 여전히 사용하는 구형 설계를 지원하기 위해 1990년대까지 제조되었다.
MCS-48 시리즈는 내부 또는 외부 프로그램 ROM과 64에서 256바이트의 내부(온칩) RAM을 갖춘 수정된 하버드 아키텍처를 사용한다. I/O는 프로그램 및 데이터와 분리된 자체 주소 공간에 매핑된다.
MCS-48 시리즈는 결국 매우 성공적인 MCS-51 시리즈로 대체되었지만, 저렴한 비용, 넓은 가용성, 메모리 효율적인 1바이트 명령어 세트, 그리고 성숙한 개발 도구 덕분에 2000년까지도 상당히 인기를 유지했다. 이 때문에 TV 리모컨, 컴퓨터 키보드, 장난감과 같이 대량 생산되고 비용에 민감한 소비자 가전 제품에 사용되었다.
8049는 2KB의 마스크 ROM (8748 및 8749는 EPROM을 가졌다)을 가지고 있으며, 이는 4KB의 외부 ROM으로 대체될 수 있다. 또한 128 바이트의 RAM과 27개의 I/O 포트를 갖추고 있다. 마이크로컨트롤러의 발진기 블록은 클록 입력 주파수를 3으로 나눈 다음, 그 결과를 다시 5개의 머신 상태로 나눈다. 최대 11 MHz의 크리스탈 주파수를 사용하면 단일 사이클 명령어의 0.73 MIPS가 생성된다. 명령어의 약 70%는 단일 바이트 및 단일 사이클 명령어이지만, 30%는 두 사이클 또는 두 바이트가 필요하므로 일반적인 성능은 0.5 MIPS에 더 가깝다.
MCS-48 시리즈는 일반적으로 컴퓨터 및 터미널 키보드에 사용되어 키 누름을 디지털 회로가 이해할 수 있는 프로토콜로 변환했다. 이는 또한 직렬 통신을 가능하게 하여 외부 키보드의 케이블에 필요한 도체 수를 줄였다. 마이크로프로세서는 적어도 1972년부터 키보드에 사용되어 이전의 개별 설계를 단순화했다. 8048은 1978년 출시 이후 이 응용 분야에 사용되어 왔다.
1979년에 출시된 Tandy/Radio Shack TRS-80 Model II는 키보드에 8021을 사용했다. 8021 프로세서는 키 매트릭스를 스캔하고, 스위치 닫힘을 8비트 코드로 변환한 다음, 해당 코드를 직렬로 주 시스템의 키보드 인터페이스로 전송한다. 또한 표시 LED를 켜거나 끄는 명령을 수락하기도 한다. 8021은 TRS-80 모델 12, 12B, 16, 16B 및 Tandy 6000/6000HD의 키보드에도 사용되었다.
오리지널 IBM PC 키보드는 8048을 내부 마이크로컨트롤러로 사용했다. PC AT는 PC의 인텔 8255 주변 장치 인터페이스 칩을 I/O 포트 주소 에서 포트 주소 및 를 통해 액세스할 수 있는 8042로 대체했다. 8042는 키보드 인터페이스를 관리할 뿐만 아니라 AT의 인텔 80286 CPU를 위한 A20 라인 게이팅 기능을 제어했으며, 소프트웨어 명령을 통해 80286을 재설정할 수 있었다 (80386 및 이후 프로세서와 달리 80286은 재설정 외에는 보호 모드에서 리얼 모드로 전환할 방법이 없었다). 이후의 PC 호환 기종은 8042의 기능을 슈퍼 I/O 장치에 통합했다.
8048은 마그나복스 오디세이² 비디오 게임 콘솔, 코르그 트라이던트 시리즈, 코르그 폴리-61, 롤랜드 주피터-4 및 롤랜드 프로마스 아날로그 신시사이저에 사용되었다. 신클레어 QL은 밀접하게 관련된 인텔 8049를 사용하여 키보드, 조이스틱 포트, RS-232 입력 및 오디오를 관리했다. ROM이 없는 8035 변형은 닌텐도의 아케이드 게임 동키콩에서 배경 음악을 생성하는 데 사용되었다.
파생 마이크로컨트롤러.
필립스 반도체 (현재 NXP)는 이 시리즈를 생산할 라이선스를 소유하고 있었으며, 이 아키텍처를 기반으로 MAB8400 제품군을 개발했다. 이들은 I²C 인터페이스를 통합한 최초의 마이크로컨트롤러였으며, 초기 필립스 (마그나복스 미국) 콤팩트 디스크 플레이어 (예: CD-100)에 사용되었다.
인텔 MCS-96은 임베디드 시스템에서 흔히 사용되는 마이크로컨트롤러(MCU) 제품군이다. 이 제품군은 흔히 8xC196 제품군 또는 80196(제품군 내에서 가장 인기 있는 MCU)으로 불린다. 이 MCU는 주로 하드 디스크 드라이브, 모뎀, 프린터, 패턴 인식 및 모터 제어에 사용된다. 2007년에 인텔은 MCS-96 마이크로컨트롤러 제품군 전체의 단종을 발표했다. 인텔은 "이 부품에 대한 직접적인 대체품은 없으며 재설계가 필요할 가능성이 높다"고 언급했다.
MCS-96 제품군은 포드 EEC-IV 엔진 컨트롤러 제품군의 첫 번째 프로세서인 인텔 8061의 상업적 파생으로 시작되었다. 8061과 8096의 차이점으로는 메모리 인터페이스 버스가 있는데, 8061의 M-버스(M-Bus)는 메모리 장치에 트래킹 프로그램 카운터가 필요한 '버스트 모드' 버스이다. 또한 두 부품의 I/O 주변 장치에도 상당한 차이가 있었다. 8061은 8개의 HSI(펄스 측정) 입력, HSI 핀과 완전히 분리된 10개의 HSO(펄스 생성) 출력, 그리고 8096보다 더 많은 채널을 가진 비샘플링 10비트 ADC를 가지고 있었다. EEC-IV와 8096의 많은 차이점은 I/O 핀 수를 줄이기 위해 핀을 공유하고 더 전통적인 메모리 인터페이스 버스에 핀을 사용하려는 노력에서 비롯되었다. 8096에는 8061에 없었던 온칩 프로그램 메모리도 있었다.
포드는 1982년에 콜로라도 스프링스에 포드 마이크로일렉트로닉스(Ford Microelectronics) 시설을 설립하여 EEC-IV 제품군을 보급하고, 자동차에 사용될 다른 맞춤형 회로를 개발하며, 비소화 갈륨 집적 회로 시장을 탐구했다. 이 제품군에는 1메가바이트의 메모리를 주소 지정할 수 있는 메모리 컨트롤러를 통합한 8065가 포함되었다.
이 마이크로컨트롤러 제품군은 16비트이지만, 일부 32비트 연산도 수행한다. 프로세서는 16, 20, 25, 50 MHz로 작동하며, 3개의 작은 제품군으로 나뉜다. HSI(고속 입력) / HSO(고속 출력) 제품군은 16 및 20 MHz로 작동하고, EPA(이벤트 프로세서 배열) 제품군은 모든 주파수에서 작동한다.
MCS-96 제품군의 주요 특징은 대용량 온칩 메모리, 레지스터-레지스터 아키텍처, 세 가지 피연산자 명령, 8비트 또는 16비트 버스 폭을 허용하는 버스 컨트롤러, 그리고 대규모 블록(256개 이상)의 하드웨어 레지스터에 대한 직접 플랫 어드레싱을 포함한다.
809x/839x/879x 제품군.
809x/839x/879x IC는 MCS-96 제품군의 구성원이다. MCS-96은 8x196 제품군으로 알려져 있지만, 8095가 이 제품군의 첫 번째 구성원이었다. 나중에 8096, 8097, 8395, 8396, 8397이 제품군에 추가되었다.