KR20210113574A - A process model using a single large linear registers, with new interfacing signals supporting FIFO-base I/O ports, and interrupt-driven burst transfers eliminating DMA, bridges and external I/O bus - Google Patents

Abstract

The present invention relates to a processor or CPU architecture, and specifically, to a processor or CPU architecture which implements many technologies proven to enhance a synchronous burst data transfer. The Input-Output (I/O) is uniformly viewed and treated as an individual First-In-First-Out (FIFO) device. A plurality of memory areas are classified as user stack, kernel stack, interrupt stack and procedure call stack. Only one I/O arbiter is necessary for a CPU model which arbitrates between a plurality of FIFOs substituting data caches for on-chip implementation. Accordingly, conventional data transfer techniques using Direct-Memory-Access (DMA), bus control and lock signals, and the like may be eliminated. In order to support an interrupt-driven, FIFO-based I/O and synchronous burst data transfer, the CPU employs a simple linear large register set without bank switching.

Description

A process model using a single large linear register that achieves interrupt-driven burst transfer that excludes DMA, bridges, and external I/O buses, new interface signals support FIF-based I/O ports, and linear registers, with new interfacing signals supporting FIFO-base I/O ports, and interrupt-driven burst transfers eliminating DMA, bridges and external I/O bus}

The present invention relates to microprocessors and computer architectures.

History of CPU Architecture

Many current processor or CPU architectures are taken from the IBM 360 (published in 1064) with CISC and RISC design features. This design takes into account multiprocessing conditions with specific instructions for business and scientific necessity. Most CPU designs were designed to use contemporary operating system (OS) software. Computers so far have been built with discrete logic gates, and as a result, the entire system occupies several rooms in one house. The invention of a processor using discrete logic was published in 1964 by G.H. U.S. Patent #3,401,376, filed by Barnes on September 10, 1968, and U.S. Patent #3,518,632, filed June 30, 1970 by Threadgold in 1967.

The history of CPUs can be said to have started in 1961, when Facherild first commercialized ICs. The processor system introduced in Patent 3,462,742, which was applied by Henry S. Miller of RCA in 1966 and registered in 1969, consists of many ICs having about 200 logic gates. This is beyond all discrete logic circuits.

Soon after, it became known that if some modules constituting a processor were to be reduced to one IC, the next step was to simply put everything into one IC, which could be a microprocessor. In 1971, Intel produced the first microprocessor, the Intel 4004, integrated into a single 16-pin IC, which consisted of a 4-bit data bus, a 12-bit address bus, 16 4-bit registers, and 4 12-bit registers. and operated at a 750 kHz clock. It is the simplest of all CPUs implementing the classic Von Neumann architecture, and became the starting point for the CPU architecture.

In the '70s, Unix was used in mainframe computers for university and industrial use. In the late 70s, when PCs were mass-produced, most OSs were Apple DOS and CP/M. Multitasking for mass use, the IBM PC was the same Unix version as Berkeley's BSD Unix, and not long after Santa Cruz Operations' Zenix was in use, IBM developed the IBM PC in 1981, and it wasn't until the 1990s when Windows began. MSDOS was used.

In 1988, POSIX (Portable-Operating-System-Interface-for-Unix), a portable operating system, was developed and used a kernel with constant function calls that describe the consistent behavior of processes that can be connected to all high-performance CPUs. It standardized the OS with kernel and API (Application-Interface) that affect CPU architecture.

Almost all new and popular CPU architectures were designed on the Intel Pentium in the mid 80's, since then ARM in 1985, MIPS R2K in 1986, Sun Sparc in 1987, AMD 29K in 1988, Intel i960 in 1988, 1992 There's the Motorola PowerPC from 1994, the DEC Alpha from 1994, and the Intel Itanium from 2002.

Almost all of these CPUs were complex designs, with the exception of the 1960 ARM and AMD 29K. The latter architectures are superscalar, superpipelined, with branch prediction and other complex schemes. Many concepts, such as Sun Sparc's rotating window, have proven to be bottlenecks and inefficiencies. Unfortunately these designs didn't have many desired features before Posix was set up, especially pre-Linux.

When applying to a Posix environment such as a PC, in order to add a module and packet data flow in a router, it is necessary to use an I/O expansion bus such as DMA, multi-bridge, multi-arbiter, and PCI on the CPU board. Such a CPU must have these conventional elements, so that it has a complex interfacing scheme.

The need for a simpler and more powerful CPU architecture in the Posix environment emerges

Simplicity in this invention means easy to learn and easy to implement within the Posix interface that describes a powerful computing environment. Ease of learning comes from streamline architectures, concepts and models with few or no special cases, but also from better mapping of CPU processes in the Posix environment.

It is better to implement a special system design that is easily done with less complex interfacing signals on the SOC (System-On-Chip) or board, and as a result, it is better to isolate the troubleshooting problems after fabrication more simply. For example, troubleshooting a system with two arbiters and two bridges is much more difficult than a system with no bridges and one arbiter. Consider the complexity of the communications processor used in many high-end routers, such as the IXP435, which has three bus bridges and three bus arbiters each. Also, IA-32 (Intel i86) on PC with North bridge, South bridge and other arbiter-bridge pairs are roughly similarly complex. For CPUs of this architecture, it is necessary in any case to have no bridges at all and only one arbiter.

Most CPUs require DMA, Lock and Bus Request signals, as well as complex support protocols for transferring data to block I/O devices when enhanced using commonly used and understood interrupt signals. These signals require a functioning interrupt mechanism, but vice versa; Interrupts can avoid them. Thus, this invention relies heavily on an interrupt-driven mechanism.

Reducing complex interface signals should be done by reducing everything to a bunch of FIFOs and simplifying the I/O device when it can handle it. All peripherals, including multi-core CPUs and parallel array architectures, also simplify connectivity.

The other mechanism is a simple vector ID, originating in the descriptor tables of old Burroughs computers from the 70's, and accessing process-control-block (PCB) descriptors while valuable for fast interrupt response in a given memory frame and fast access of parameters. has been proven to be an effective means of

As can be seen from this, high-performance computing yield cannot be achieved without efficient data transmission means. This is accomplished with synchronous burst data transfer via block memory (register-memory) transfers, as well as I/O via FIFO.

Summary of the invention

The present invention describes a CPU model that uses interfacing signals to support interrupt-driven processing of FIFO-based I/O with synchronous burst data transfer. This CPU model supports an architecture that efficiently maps the OS of the PC and the corresponding instruction set to the Posix interface underlying the embedded system.

This CPU model creatively uses several well-known techniques to achieve high data yields and use them for new data processing.

Proven techniques are synchronous burst data transfer, FIFOs, separate memory regions per stack, autonomous local I/O registers (IORs), and vector descriptors. Complex techniques such as cache memory manipulation, register renaming, pipelining, and other data-dependent manipulation schemes were excluded. Basically, large data caches whose validity is probabilistic are replaced by deterministic arrays of FIFOs.

This CPU model revolves around an interrupt-driven handshaking scheme and uses a new set of synchronous burst data transfer signals with an interrupt mechanism of the commonly understood INT-INTA (Interrupt-Interrupt Acknowledge) signal pair. This simplifies the concept of interrupt-driven processes. If all events are interrupt-driven, many existing bus control signals can be cleaned up, eliminating I/O buses and their variants such as DMA, busbridge, multi-arbiter, and PCI.

Interrupt-driven processes should be very well adopted in multitasking kernels such as Linux, which have a daemon process scheduler, and interrupting a running process by a timer tick means it is interrupt driven.

1 is a block diagram showing the internal registers and buses forming a Chun-U model;
Fig. 2 is a block diagram of interface signals showing the ISR, vector table and relationship with the device;
Fig. 3 is a block diagram of the I/O arbiter companion module of Fig. 2, a block diagram of a CPU model having 9 control bodies and eliminating I/O buses such as DMA, bridge, one or more arbiters and PCI;
4 is a block diagram of an autonomous counter and time-of-day implemented on an IOR independent local bus;
5 is an FSP composed of a 20-bit FP and a 12-bit SP used in a function call; Block diagram showing Frame-Pointer and Stack-Pointer pairs;
6 shows an atomic block instruction pair of atomic1 and atomic2 that toggles bit-31 from 0 to 1 in an arbitrary instruction to execute instructions 1-5 atomically or without interruption.

Hereinafter, the present invention will be described in detail with reference to the accompanying drawings, but it should be understood that this description is merely an example and does not limit the scope of the invention.

In Fig. 1, the CPU model provides a _{set of 256 working registers 100 denoted by r 0} to r ₂₅₅ , which can be used as both data pointers and address pointers. Register usage is orthogonal, and any instruction can be applied to any register. These registers are the local user mode register 101 _{of r 0} ~ r ₁₅ , the global user mode register 102 of _{r 16} ~ r _{31 , the local kernel mode register 103 of r 32} ~ r ₄₇ , and the rest for interrupt mode. It is divided into registers 104; They are separated and assigned according to the use of the interrupt source 208,220, such as a USB device or other peripheral, and a use for a common coherent task, such as a processor scheduler. One large register space 100 greatly reduces the need for parameter passing.

The rules governing the register set are as follows: user mode _{can only see r 0} ~ r ₃₁ (101,102), kernel mode and interrupt mode (103,104) can see all 256 registers without bank switching; The context switch of the user mode 101 stores registers r ₀ ~ r ₁₅ , and the kernel mode context switch stores registers r ₃₂ ~ r ₄₇ ( 103 ) in each memory location; Registers r ₁₆ to r ₃₁ (102) are used to pass parameters for both user mode and kernel mode.

There are a total of 12 control registers, which consist of 4 main current control registers: current FS (105; Flags/Status), current FSP (106; Frame:Stack-Pointer), and current PC (107; Program). Counter), second current PC1 (108; Program Counter); Four FSP1 (109; Frame:Stack-Pointers) for user mode stack, FSP2 (110) for kernel mode stack, FSP3 (111) for interrupt stack, and FSP4 (112) for function call stack.

When supporting FIFO buffer-oriented I/O, the I/O arbiter 201 is implemented in the CPU core 200,306, or a separate I/O arbiter chip 201,300 using CPU synchronous burst transfer, and another arbiter , DMA mechanism, bus control signal and FIFO buffering mechanism to eliminate I/O bus such as PCI.

In addition to the CPU control registers, there is a dual-port local I/O register file (IOR) 117,400, which has a total of 1024 words of addressable memory, one word equivalent to 4 bytes or 32 bits. These IOR (117,400) files use the same signals as external I/O addressing: I/O read (IORD) signal 210 and I/O write (IOWR) signal 211. External I/O addressing signals are used to access the I/O arbiter chip 201,300 followed by the FIFOs 303-307 of the device (see FIG. 3).

In the first embodiment, data transfer to an I/O device in a typical computing process is via a FIFO, here FIFO-1 (207); The CPU 200 in kernel mode executes some data operation on the data blocks in the memory 202 . Data blocks are moved throughout the CPU registers 103 for best efficiency, one register set block at a time. When the operation is finished, part of the register block is sent to another memory location.

Thus, a block of data must be read into the memory frame Frame-1 (229) before the CPU set of operations begins as described above. This is done by the I/O port to the memory read during synchronous burst data transfer. CPU instruction 203 reads FIFO-1 207 using IORD signal 210, SYNCLK 214, SYNSTP1 215, SYNSTP2 216 signals until FIFO-1 207 is empty. The I/O arbiter 201 then activates SYNSTP2 216 to mark the end of the data, at which time the CPU 200 stops reading.

Similarly, the IOWR signal 211 , SYNSTP1 215 , and SYNSTP2 216 signals are used for writing to the FIFO-1 207 connected to the USB device 208 . Burst writes and writes a memory frame from Frame-1 (208) to FIFO-1 (207), and when a predetermined data block ends, the CPU 200 informs the I/O arbiter 201 that the transmission is complete. Activate the SYNSTP1 (215) signal.

Meanwhile, as described above, receiving data from a device such as the USB device 208 is the same as sending data to the FIFO-1 207 . When the FIFO-1 207 speaks to the I/O arbiter 201 , the arbiter activates an INT (interrupt) signal 212 . The I/O arbiter 201 receiving the INTA (interrupt acknowledge) signal 213 puts the FIFO-1 207 vector ID on the data bus 209 . The CPU 200 reads this vector ID and jumps to the address corresponding to this ID. The CPU 200 enters the kernel mode and all 256 registers 100 from r0 to r255 become available to the CPU, at this time the CPU only inverted for the FIFO-1 207, that is, the ISR 203; interrupt- service-routing) is used. The ISR knows a request from FIFO-1 207 to burst read data using the IORD 210, SYNCLK 214, SYNSTP-1 215 and SUNSTP2 216 signals. When the burst read ends, the CPU 200 activates the SYNSTP1 (215) signal indicating the end of the read to the FIFO-1 (207). The ISR 203 exits the interrupt when executing the reti 206 instruction.

The second embodiment of the present invention mimics DMA transfer. In a multiprocessor connection, when another device or another CPU, CPU-2 (219), wants to access the data bus, INT through the I/O arbiter INT21) signal 220 Activating signal 212, CPU 200 jumps to the address assigned to the vector ID of CPU-2 219. In ISR 203, CPU instruction busd 205 disables all buses and executes a stop instruction so that CPU200 activates HALT signal 217 and stops instruction execution and hardware UHALT from CPU-2 219 Wait for signal 218 . At this time, the CPU-2 (219) is the CPU address (231) until the CPU (200) returns to the normal state and operates the UHALT signal (218) that executes the reti (206), which is the next instruction that causes the ISR to exit the interrupt. and access to databus 209.

As another example of a DMA transfer, a CPU-3 (221) connected to the I/O arbiter 201 using a FIFO-4 (222) can access a memory block or memory buffer, Frame-1 (229). The I/O arbiter 201 activates the CPU INT signal 212, receives the INTA signal 213, and then the device interrupting by the I/O arbiter 201 sends the ID of the device 221 to data. It is placed on the bus 209 . The CPU 200, knowing the source, executes a routine to synchronously burst transfer the memory buffer Frame-1 (229) to the FIFO-4 (222) like all other devices without the need to disable the bus.

In a third embodiment of the present invention, a hardware interrupt mechanism is designed to issue near-zero housekeeping instructions for fast and efficient interrupt processing in ISR 203. An interrupt request is triggered by an INT signal 212 from an external source, such as an I/O arbiter 201 . CPU 200 replies with INTA signal 213 , then, via I/O arbiter 201 , an interrupting device such as USB device 208 puts the vector ID of the device on databus 209 . . Then, the CPU 200 reads this vector ID and jumps directly to the vector ID address. In the vector 'va', 'a' can take up to 18 bits as an ID number. The CPU 200 recognizes only 256 hardware interrupt sources reserved in the hardware interrupt vector memory space 226 .

Before executing the first instruction in the ISR 203 corresponding to the vector ID, the current main control registers constituting the FS 105, FSP 106, PC 107 and PC1 108 are configured as below interrupt mode are stored in dedicated sets of 4 copies of the registers in: FS-I (113; interrupt Flags/Status), FSP-I (114; interrupt Frame-Stack-Pointer), PC-I (115; interrupt Program-) Counter), and PC1-I (116; second interrupt Program-Counter).

Then, the current kernel mode FSP 106 is loaded like the FSP3 111, the PC 105 is loaded with the pointer in the vector ID, and the ISR starts. Other instructions are unnecessary, the first instruction may contain the actual ISR 203 code; Only the reti(206) instruction is required. In interrupt mode, all 256 registers 100 r ₂₅₅ ~r ₀ are visible, where r ₂₅₅ ~r ₄₈ (104) is almost customarily reserved.

When the reti(206) instruction leaves the ISR(203), the previously saved interrupt registers FS-1(113), FSP-I(114), PC(115) and PC1-I(116) restore the previous machine state. is copied to the current main control registers FS(105), FSP(106), PC(107) and PC1(108).

In a fourth embodiment of the present invention, FIFOs are shown in which the CPU architecture depicts the interaction mechanism of the interface lines and eliminates the DMA bridge one or more arbiters and I/O buses such as PCI. The I/O arbiter 201 of FIG. 2 is denoted as the I/O arbiter 300 in FIG. 3 to show how to get rid of these traditional CPU elements. Although a separate companion chip for the I/O Arbiter 201 is described herein, this chip can be built into the CPU 306 itself to replace the on-chip data cache (common with other processor modules) for the FIFO. may be

In FIG. 3 , the interface ports for an I/O device as in Device-1 are all identical, and consistent when presented to a port engine such as I/O-1 port engine 302 . The main function of the port engine is serial-to-parallel conversion when there is an input, and vice versa when there is an output to serial devices. Data between devices is stored in a memory buffer of a FIFO such as FIFO-1 (303). Multiple distributed devices can be connected to each I/O port engine 302-308, where data transfer is handled autonomously by the engines. In a FIFO such as FIFO-1 303, the arbiter+interrupt engine 304 autonomously decides which FIFO serves, according to rules configured during initialization time. The CPU 306 uses the nine CPU control signals 305 to perform synchronous burst data transfer in the form of DMA between FIFOs as suggested by the arbiter+interrupt engine 304 . Also, during initialization, the arbiter+interrupt engine 304 is configured to fit the length of the data buffer of the FIFOs 303 to 307. For very slow devices, the buffer can be very small, taking a minimum of only 1. For very high-speed devices, you can set the buffer size to its maximum value. Therefore, a bridge is unnecessary, because various devices with different data rates can be accommodated in the buffer size in the FIFOs 303 to 307. In addition, since only one I/O arbiter of the arbiter + interrupt engine 304 is required for many FIFOs, it can be implemented with one chip, thereby eliminating the I/O bus such as PCI.

In a fifth embodiment of the present invention, an independent local bus 406 is created using local I/O register files (IORs) 117,400, which may be dual-port, which local bus is an autonomous hardware function or engine timeout. (time-of-day) function can be implemented. IORs 117 and 400 are addressed by a 10-bit word for up to 1024 registers in kernel mode, and are also used to store local system variables.

In the embodiment of Fig. 4, a hardware real-time clock engine that periodically updates the time-of-day counter 404 is configured from counter-1 (402) and counter-2 (403) which are other counters.

When the stable crystal clock source 401 operates the first counter counter-1 402 at a constant frequency in the megahertz range, this counter becomes the second counter counter-2 (403) after a certain period of time according to the word written there. ), and this counter updates the time-of-day counter 404 after a predetermined time according to the word written there.

Similar to the time-of-day engine, the timer engine timer-1 (405) is implemented. The CPU 200 can read all the counter registers 402 to 405 through the main data bus, so as to implement all timer related functions. The time-of-day register 404 can interrupt events as needed by the Linux cron daemon. Although only two timers are shown in FIG. 4 , those skilled in the art can configure two or more timers using IORs 117 and 400 , which autonomously operate an independent local data bus 406 through the IOR and main data operation. This is because it operates simultaneously with the bus 407 .

In the sixth embodiment of the present invention, a plurality of Frame-Stack-Pointers are implemented to support the system sys va command using the procedure call command related to the fn va function and the vector 'va' described in claim 3 . In addition to the jump and link (j1 a) instructions, and in addition to the local call instruction (call a) that is used for some task and uses the FSP 106,500 like this task, the CPU 200 implements the function call instruction fn va using a vector mechanism. Here, 'fn' is a mnemonic for the dms function, 'v' is a vector emer, and 'a' is a vector number or ID. This function call can be called from any task or program and is reentrant.

In FIG. 5, FSPs 106,500 are defined as a 20-bit FP (frame pointer) 501 and a 12-bit SP 502. In FIG. In this way, the size of the SP 502 can be 1k words. This FP:SP word or FP-0 504 shown by FSP 106,500 is initialized to 0x00100000.

The basic mechanism of all function calls is shown in FIG. 5 . For every function call, a new FP 501 is simply created by incrementing the example 501 . This is done automatically by the CPU 200 by adding 1 to bit-12(d ₁₂ ) 503 or likewise adding 0x1000 to the FSP 500 word. The current FSP 500 is stored in the FSP4 112 designated as the FSP for the function call fn va. Current FS 105 , FSP 106 , PC 107 and PC1 108 are stored at an offset from the beginning of FP-0 504 . The entire local register-set 101 is stored at an offset from the location specified by FP-0 504 . The PC 107 is loaded like a pointer to the function vector address, and the program is transferred.

Conversely, with a retf instruction (returning from a function call), the current FP 501 is decremented, and all registers are loaded at the offset from the new FP 501 as the stored set. This is done automatically by the CPU 200 by subtracting 1 from bit-12(d _{12 ) 503 or QO 0x1000 in the FSP 500 word.} The program is originally transferred to PC 506 . As this operation proceeds step by step, in the next retf instruction, the FP 501 is decremented again and the recovery process is repeated.

In the seventh embodiment of the present invention, as a CPU architecture that generates an instruction using a vector ID or vector 'va', in addition to the interrupt descriptor for the ISR 203, a descriptor table such as a process-control-block (PCB) and a position Just a few instructions elsewhere, such as a FIFO buffer in main memory for independent code, are examples. Vector IDs are reserved in memory locations from address space 0 to 0x7ffff, as hardware interrupt vectors 226, i.e. kernel call vectors 227 from 0x0 to 0xff, 0x100 to 0x2ff, for function call vectors and other descriptor tables. , and the remainder from 0x300 to 0x1ffff (228).

In the FIFO embodiment, the FIFO-1 207 memory buffer, Frame-1 229, can be denoted by v0x700, which is at memory location 0x700x4=0x1C00. Thus, memory location 0x1C00 contains the FIFO-1 main memory buffer. Similarly, when using a buffer, the data array can be set to v0x900 marked Frame-2, or the frame pointer can be placed at memory location 0x900x4=0x2400. To access the 100th array, you only need to use the following CPU instructions:

m v0x700, r ₁ → move vector v0x700 to register r ₁

m @r ₁ , r ₂ → Move the data pointed to by register r _{1 to register r 2}

Here, v0x700 is a representation of the vector 0x700, 'm' is an abbreviation of 'move', '@' means 'position', and 0x is a prefix meaning hexadecimal. Instructions are read from left to right.

r2 contains the actual pointer to the buffer array in Frame-1 (229).

The 100th member is:

m @r ₂ +100, r3 → Move the _{data pointed to by register r 2} +100 to register r ₃

or 101st member; m @r ₂ +101, r3

Once the vector ID is used to get the actual pointer, we can now use r2 as the base pointer, and access the vector ID or variable in the descriptor by indexing from the base pointer r2.

Also, you can use the vector notation jp va in the jump command; Here, 'jp' means 'jump', 'v' means vector, and 'a' means vector number or ID.

After receiving this command, the CPU transmits the PC (Program-Counter) to the vector number 'a' that designates the address 'a' x 4 including the actual PC address to jump to.

Another example of a CPU architecture that uses a vector ID and a synchronous burst transfer operation is to load a parameter frame from a memory location. A parameter frame is defined as 16 consecutive 32-bit words in memory, mapped to a set of user or kernel-mode local registers.

CPU instruction; In ms @va, r _b , 'ms' means "synchronously or burst move a data block of 16 words starting at vector 'a' into _{16 registers starting at r b} ", 'v' means 'vector', and 'a' is the vector ID.

A data block frame, also known as a frame, such as Frame-1 (229) , is the start of the vector V0x700 , which is a set or frame of 16 32-bit data words. 16 word frames are transmitted in a burst fashion every SYNCLK 214 cycle.

In the eighth embodiment of the present invention, all instructions necessary for synchronization of processes in a multiprocessing system involving memory access or device access are executed. Memory accesses are made in a location or block of critical memory. In general, atomic instruction operations, which maintain the consistency of read-modify-write sequences in persistent operations at the CPU level, augment other more flexible synchronization mechanisms, augmenting Mutex (mutually-exclusion) resources and ; At this time, if one process is accessed, other processes must wait.

In the embodiment of Figure 6, all mutex primitives are removed and replaced with one block atomic instruction with a pair of prefixes and suffixes atomic1 (600) and atomic2 (601). Accordingly, the atomic instruction TKd surrounds the instruction block 602 for atomic execution. The instructions in block 602 execute sequentially and without interruption, no matter how long. The atomic1(600)-atomic2(601) pair can make all instructions atomic by simply setting MSb bit31(603) of the instruction word 604 to "1" indicating the atomic instruction shown in FIG. . Therefore, existing atomic instructions such as xchg of intel 8088 and compare-exchange and compare-decrement of other CPUs can be eliminated. It is also a superset of block-type atomic instructions, such as those implemented in Intel x86 or IA-32, that can be used by applying only a few selected instructions.

The atomic1(600)-atomic2(601) pair is only visible to the programmer at the source level, like assembler directives.

Claims (15)

a. One linear 256 operation registers that are not bank switched, classified according to modes including user mode, kernel mode and interrupt mode;
b. FIFO buffer-oriented I/O (Input/Output), which is an interrupt-driven device as if it were CPU-like;
c. An I/O arbiter integrated into the CPU's core or implemented as a separate I/O arbiter chip, which eliminates the CPU's need for direct-memory-access (DMA) mechanisms, bus control signals, bus bridges, and I/O buses. ; and
d. For a CPU comprising: a local I/O or I/O register (IOR) integrated within the CPU with uniform I/O addressing and external I/O:
the CPU performs separate memory allocation for four stack operations including a user stack, a kernel stack, an interrupt stack, and a procedure call stack;
The CPU according to claim 1, wherein the CPU performs a consistent data transfer method using signals supporting block and synchronous burst modes. According to claim 1, wherein the CPU is a memory RD (read) signal, memory WR (write) signal, IORD (I/O read signal), IOWR (I/O write signal), SYNCLK (synchronous data transfer clocking signal), Characterized in using a plurality of signals including synchronous data transfer first stop signal (SYNSTP1), synchronous data transfer second stop signal (SYNSTP2), interrupt signal (INT), interrupt-acknowledge signal (INTA), HALT signal and UHALT signal CPU. The CPU according to claim 1, wherein the CPU includes an instruction including hardware and software interrupts and a move (load-store) instruction to move a vector va to a register r1 (where v is a vector and a indicates a vector number or ID). A CPU characterized in that it uses an instruction set using a vector representation and a criterion that is used consistently in the CPU. The method according to claim 1, wherein the CPU sets the instruction word to bit-31(d31) in a little-endian instruction to make all instructions atomic, and bit-31(d31)=0. All instructions are executed normally, but are atomic when bit-31(d31)=1, and instruction blocks with bit-31(d31)=1 are executed atomicly, eliminating the need for atomic instructions, indicating that the instruction block may be atomic Characterized by the CPU. The CPU according to claim 1, characterized in that it has 256 linear registers operable by CPU instructions, the registers being numbered from r0 to r255 and divided into four sets below.
a. a first set (r0-r15) containing 16x32-bit local registers for user mode;
b. a second set (r16-r31) with 16x32-bit local registers for user-mode global registers;
c. a third set (r32-r47) with 16x32-bit local registers for kernel mode; and
d. Fourth set (r48-r255) with kernel-mode global registers and 208x32-bit registers for interrupt service. 2. The CPU of claim 1, wherein the programming model finds the bottom among the linear 256 registers r0-r255.
a. User mode registers r0~r15;
b. User mode local register set (r0~r15);
c. register sets (r16-r31) as user-mode global registers that remain unchanged across all processors;
d. All 256 registers without bankswitching in interrupt mode and kernel mode, which is also a kernel mode process;
e. Register set r32-r47 reserved for kernel local registers; and
f. A set of user-mode global registers (r16-r31) reserved for use in passing parameters from the user-mode local register set (r0-15). 2. The CPU according to claim 1, wherein the CPU has 12 CPU control registers that are not visible to the programmer, these 12 CPU control registers are necessary to describe the current CPU execution state to ensure an accurate return to the previous function call, and The control registers are divided as follows, and the 12 CPU control registers, except for the FS register, are not accessed and operated by software instructions, and are linearly 256 in the FS register to block bits from the field as a result of an internal hardware trap. A CPU characterized in that access to the FS register is allowed only by kernel-mode instructions moving through the register set:
I. a. Current FS;
b. Current FSP;
c. Current PC;
d. 4 main CPU control registers consisting of PC1;
II. a. FSP1 for user stack;
b. FSP2 for kernel stack;
c. FSP3 for interrupt stack;
d. 4 FSPs composed of FSP4 for procedure call or function call stack;
Ⅲ. a. Interrupt FS-I;
b. interrupt FSP-I;
c. Interrupt PC-I;
d. 4 copies of the main CPU control registers in interrupt mode configured with interrupt PC1-I. 8. The method of claim 7, wherein the CPU architecture of the CPU implements FP:SP defined as a pair of FP and SP in a single internal CPU register denoted FSP; FSP is defined as a 20-bit FP and a 12-bit SP, and in any given FSP word FP is defined as bit-31 through bit-12, d31 through d12, where addressing in this CPU architecture is and bit-1 and bit-0 (d1 & d0) are unused, so the SP contains up to 1024 words of register set, passed parameters and pushed words; SP is always an offset to FP; A CPU, characterized in that whenever SP or d11 - d2 both reach "1" and are 0xfff, a hardware trap, which is an interrupt to vector ID V254, occurs with the appropriate set of bits in the trap word. 4. The maximum of claim 3, wherein the CPU corresponds to 131,072 (0x20000) vectors of vector ID V0 to vector ID v0x1ffff, including pointers to interrupts, system calls, descriptor-tables, and others denoted by v0x0 to v0x1ffff. A CPU that implements 128k, characterized in that the vectors are distinguished as follows:
a. v0 to v0xff assigned to kernel-mode hardware interrupts;
b. v0x100 ~ v0x2ff assigned to system call vector in kernel mode;
c. User mode, descriptor-table pointer for PID (process ID), and v0x300 ~ v0x1ffff divided among function call vectors in PCB (Process-Control-Block). 3. The CPU according to claim 2, wherein the CPU generates three interface signals for synchronous burst data transfer to SYNCLK, SYNSTP1 and SYNSTP2, and the block transfer of all data arrays in main memory for a user register set and a kernel register set is performed by the CPU. It is transmitted in a burst using the three interface signals controlled by A bit word is transmitted, and the SYNCSTP1 and SYNCSTP2 signals indicate the end of transmission. The CPU according to claim 2, wherein the CPU uses only one main bus arbiter with FIFO, and a plurality of bus arbiters are unnecessary, and only one arbiter is required even in a complex design. 3. The CPU of claim 2, wherein the CPU uses the INT-INTA signal pair with sync signals SYNCLK, SYNSTP1, SYNSTP2 without disabling the memory bus. 3. The method according to claim 2, wherein when the CPU disables the memory bus by using the CPU command busd (bus disable), the DMA can be executed by mimicking the conventional method, and the execution is performed using the synchronization signals SYNCLK, SYNSTP1, SYNSTP2 and other two methods. CPU, characterized in that it is made using the INT-INTA signal pair together with the signals HALT and UHALT signals. According to claim 1, wherein the CPU writes an IOR (I/O register file) consisting of a memory space of 1024 words corresponding to 32-bits, in which one word is accessed by 12-bit byte addressable lines A0 to A11. Implementing, the IOR is an internal dual-port read-write memory for storing frequently used variables and for implementing autonomous I/O devices (including event counter real-time clock and device configuration); The CPU avoids and does not need to poll the main memory bus access, which can implement hardware functions that require an independent local bus that is not blocked by CPU memory bus operation; IOR is the portion of the processor I/O addressing space that uses IORD and IOWR to access the device containing the I/O arbiter chip; A CPU characterized in that IOR is implemented internally. 2. The method of claim 1, wherein the interrupt stack provides interrupt services; Currently the main CPU control register consists of FS, FSP, PC, PC1; CPU, characterized in that the following CPU registers are each stored in a corresponding copy of the interrupt storage register.
a. Interrupt FS-I;
b. interrupt FSP-I;
c. Interrupt PC-I; and
d. Second Interrupt PC1-I.

Images