현재 메모리 모델에 대해 공부를 진행하고 있는데, 몇 가지 궁금한 것이 있어 질문드립니다.메모리 리오더링이라는 개념이 주로 나오고, DSB에서는 명령어 리오더링 개념도 한 번씩 나오는데, 이것에 대해서 Arm 아키텍처가 성능 향상을 위해 하드웨어적으로 out-of-order-execution을 수행하게 되고 그 일환으로, 각각 메모리 리오더링과 명령어 리오더링이 진행된다. 라고 이해해도 되는걸까요? 또한, 리오더링이라는 작업이 명령어를 파이프라인에서 fetch한 다음 그 안에서 순서를 바꿔서 실행을 하는 것인지, 아니면 처음부터 바뀐 순서대로 fetch를 해서 실행을 시키는 것인지 궁금합니다! dmb 배리어 명령어에 대해서, Arm 문서에는 dmb가 실행완료를 보장하지는 않는다는 식으로 나와있는데, 예를 들어,strdmbldr           이런 순서로 명령어가 있을 때 실행 순서만 잡아주는 것이라면 str 이후에 바로 ldr이 수행되는데 ldr이 먼저 완료되는 경우도 있지 않을까요?           그렇다면 이런 경우에는 str과 ldr의 실행 순서를 유지하는게 효과가 없을 것 같은데 이러한 경우에는 어떻게 되는 것인지 궁금합니다. shareability에 대한 궁금증이 있습니다… shareability라고 하는 것이 배리어 명령어를 수행할 때 적용되는 범위인데, 그렇다면,  정확히 어떤 것에 대한 범위라는 것인지 잘 이해되지 않습니다. 위의 예시에서 dmb명령어가 있는 부분에 <qual>을 추가해준다고 할 때, 여기서 shareable의 의미가 배리어 명령어 이전의 작업을 모두 진행한 뒤에, 해당 데이터에 대해 정해진 범위에 동기화를 해준다고 이해하는 것이 맞을까요? 그렇다면 CPU0가 dmb/dsb/isb를 읽고 실행할 때, 동시에 CPU1이 ldr로 해당 영역에 접근하려고 하는 상황이 있다면 CPU0의 str 동작이 완료되고나서 접근하는 것인지, 그냥 업데이트되기 전의 str된 값을 읽어들이는 것인지 그런 부분들이 확실하게 이해가 잘 안됩니다. 또한, shareable domain의 영역에 대한 구분을 좀 알고 싶습니다..! 만약에 칩 안에 메인 클러스터와 서브 클러스터가 존재하고, 각각 클러스터에는 CA73 quad core, CA53 quad core와 같이 구성되어 있다면 이런 상황에서는 non-shareable, inner-shareable, outer-shareable의 범위가 어떻게 정해지는지 알고 싶습니다. 또한, outer shareable domain과 full system domain이 영역이 어떤 부분부터 다른 건지 알고 싶습니다..!  마지막으로 책이 나와있는 shareable domain에 적용하는 범위 중에서(591p), 배리어 실행 전/후 차이에서 스토어 명령어는 실행 후에 로드가 없고 스토어만 있는지 궁금합니다..!

DSB 배리어가 리소스를 더 사용한다고 하셨는데 혹시 구체적으로 어떤 리소스를 더 사용하는건지, 그런 내용을 알 수 있을까요?

안녕하세요. 1강, 2강, 3강 모두 잘 들었습니다. 문득 3강을 듣다가 궁금한 점이 생겨서 이렇게 질문 드립니다.만약 EL2, EL3에서 동작할 Software Entity를 구현하지 않은 시스템에서 hvc, smc와 같은 명령어를 실행시키면 어떻게 되는지 궁금합니다. EL2, EL3를 구현하지 않았다면 VBAR_EL2, 3 레지스터를 초기화하지 않았을 것 이므로, Exception 발생 시 PC가 이상한 주소를 가리켜 MMU가 Fault를 유발할 것 같다고 생각하고 있는데, 해당 흐름이 맞는지 궁금합니다. 만약 틀렸다면 올바른 흐름은 어떻게 되나요?SMP와 같은 멀티 코어 프로세서에서 모든 코어에서 실행중인 User App이 각각 Exception을 발생시키면, 모든 코어에서 동시에 Kernel Code가 동작하게 되는 것 인가요?Kernel, Hypervisor, Secure Monitor는 결국, Exception이 발생하고 이에 대해 HW가 대응되는 동작(SPSR_ELn, ELR_ELn, PSTATE, PC 값 수정)을 수행한 뒤에 Exception Handler의 서브루틴이 실행되는 단순한 소프트웨어 덩어리로 이해해도 괜찮을까요? 즉, User App과 같은 경우는 Linux에서 task_struct라는 구조체로 관리가 되는데 반해, Kernel, Hypervisor, Secure Monitor와 같은 소프트웨어들은 이러한 구조체로 관리되지 않을 것 같아서 문득 궁금해졌습니다.답변 주시면 감사하겠습니다!

안녕하세요, 4-2 강의 5분쯤되는 예시에서 질문이 있습니다. 명령어 셋들이 연관성이 있을 수도 있지 않나요? 포인터라면 memory 가 겹칠 수 도 있으니 사실 같은 주소를 그리킬 수도 있을 것 같아서요, (예, R1 이 R3+8 과 연관이 있다든지)그렇게 되면 어떤 주소가 들어올 지 모르니 Out of Order Execution 알고리즘이 보수적으로 진행되는 것이 맞을 것 같은데, Arm core 알고리즘 상에서는 레지스터 이름이 다르면 dependency 가 없는 것으로 파악하게 되나요?

안녕하세요,멀티 스레드 환경시 하나의 스택 공간을 사용하게 된다고 배웠는데요, arm 아키텍쳐 상에서 스레드 별로 스택을 공유하게 되는 것은 따로 지원이 되지 않는 것 같은데, 운영체제 상에서 전부 구현하게 되나요? 아니면 다른 방법이 있을까요(, arm 을 이용해서)?

software 개발 관점에서 보았을 때 arm 에서 제공하는 명령어 들을 잘 구성해서(sharability 와 함께)여러 동시성 모델을 구현한 것인가요? 저 명령어 들이 캐시간의 정보 동기화 메커니즘multi core bus 점유 같은 문제들을 다 처리해 주나요?

https://developer.arm.com/documentation/100166/0001/Programmers-Model/Processor-memory-modelhttps://m.blog.naver.com/sheld2/222021173697 Arm document 랑 St microelectronics 에서 구현한 m4 chip 인데 메모리가 묘하게 다른 것 같아요어디까지 구현했느냐의 차이인가요? 이러면 프로그램 실행에 문제가 없나요?

SoC 설계 메모리 맵과 arm 에서 말하는 메모리 맵, 그리고 process 가 보는 virtual memory map 이 다 다른데요, os 단에서 그러면 SoC 메모리 매핑 영역(memory mapped i/o) 을 모아서 운영체제에 알려주면 운영체제가 알아서 table 에 기록하게 되는 것인가요? 또 arm architecture 가 바라보는 memory map 으로 리눅스 커널의 로더 단에서 virtual memory 공간을 바꾸어주게 되는 것인가요? 역할이 다소 헷갈립니다

안녕하세요, device memory region 은가상화가 되었다고 했을 때 translation 이 어떻게 일어나나요? 혹시 그냥 바로 물리 메모리로 링크 되나요? (os 단에서)

안녕하세요 강의를 정말 잘 듣고 있습니다!!메모리 맵드 I/O에 대해 궁금한게 있어서 질문을 남깁니다.강의 내용 중 메모리 맵드 I/O 된 영역은 device memory라고 말씀을 하시면서 메모리 맵드 I/O가 된 경우 ldr str와 같은 명령어에 의해 그 영역에 값을쓰면 그와 연결된 포트를 통해 I/O장치 또는 레지스터에 값이 쓰여진다라고 말씀을 하셨는데요, 그러면 mcr mrc msr mrs와 같은 명령어를 통해 레지스터에 값을 써야 하는 것들은 메모리 맵드 I/O가 아닌건가요? 메모리 맵드 I/O된 것들은 전부 ldr str과 같은 명령어를 사용하여 값을 읽고 쓸 수 있는건가요??? 추가로 궁금한것이, 제가 잘못 알고있는것일 수도 있지만, 임베디드 레시피라는 책에 보면 메모리 맵드 I/O 같은 경우 Register 크기 만큼씩 Access 가능하다고 나와있습니다. 그렇다면 memory mapped I/O된 영역에 레지스터 크기가 4바이트인데 strb 또는 strh와 같은 명령어를 통해 read를 하면 에러가 난다고 이해하면 될까요??? 만약에 strb strh와 같은 명령어를 통해 에러가 발생한다면 그때 발생하건 exception인가요 아니면 그냥 ignore 되는건가요??? 

ISB배리어에 대해 학습을 하면서 제가 생각했을 때는 이해가 잘되지 않은 부분이 있어 질문을 드립니다. 제가 이해한 ISB배리어의 사용 이유는 다음과 같습니다.명령어는 파이프라인을 통해 페치, 디코드, 실행을 단계를 걸쳐 병렬적으로 실행된다.ISB 배리어는 시스템 레지스터를 설정한 후에 주로 사용된다.그 이유는 시스템 레지스터을 설정한 명령어가 실행되기 전에 페치된 명령어에서 잘못 설정된 시스템 레지스터 설정 값을 읽을 수 있기 때문에파이프라인에서 플러시를 통해 비우고 시스템 레지스터를 설정하는 명령어가 실행단계까지 완료된 다음에 다음 명령어를 페치를 한다. 그리고 여기서 생긴 의문은 그렇다면 굳이 시스템 레지스터가 아니라 노멀 레지스터를 읽고 쓸 때도 이런 문제가 생길테니 ISB 명령어를 사용해야하는가? 입니다. 위 글에서 부족한 부분이 있다면 그 부분에 대해서도 설명해주시면 감사하겠습니다.

MMIO는 다바이스 포트를 제어하기 위해서 DRAM의 일부 메모리공간을 사용하는 방식이 맞는지 문의드립니다.