AscetiCore ⋅ Startup sequence

At startup, AscetiCore initializes the system context from the predefined memory location: physical addresses 0x0000000 to 0x00000fe, in words, according to the diagram from “Mapping context to memory” section. The documented order of registers is preserved. There's no guarantee that all 128 words would be read; reserved data may be skipped.

After the system context is initialized, AscetiCore operates in system mode, starting from fetching the first instruction from the address determined by the newly received R15 and TSRs, and onwards.

AscetiCore ⋅ Mapping contexts to memory

From the hardware standpoint, context is just a register file − a piece of static memory with multiport access. Different ports are connected to different internal or external CPU signals or busses. For example, various bits of SR are mapped to various signals of ALU and/or shifter, while SR as a whole is mapped to the internal AscetiCore CPU data bus for LDSR, ORSR, BRSR and STSR instructuions to work.

Various duties carried out by an operating system, like task creation, serving system requests, et c., also involves an access to contexts. In other architectures it is typically done via special, usually privileged, instructions (LOADALL instructions in x86 architecture) or tinkering with call stacks.

AscetiCore do not have privileged resources for the sake of design simplicity. Also, using a call stack in AscetiCore is optional, therefore call stacks are not involved in context switching. For contexts to be accessed in software, register files are have to be mapped to the certain regions of physical memory. Paging mechanics may be used to protect those regions from unauthorized access.

One context (register file) takes 256 bytes of memory, as shown below.

AscetiCore ⋅ Short relative immediate jump

Flow control instructions