.SPACING 1
.TITLE ^^INTRODUCTION TO MSX\\
.PAPER SIZE 58,58
.FLAGS CAPITALIZE
\\
.CENTER
^GENERAL ^INTRODUCTION TO <MSX-11
.PARAGRAPH
<MSX-11 WAS CONSTRUCTED AS AN APPLICATIONS ENGINE TO ALLOW EXECUTION
OF DISTRIBUTED APPLICATIONS ALGORITHMS ON NETS OF PDP11 PROCESSORS, EACH
SUPPLIED WITH A COPY OF THE <MSX-11 KERNEL AND COMMUNICATING IN SOME
FASHION. ^THE APPLICATIONS ARE PRESUMED TO RUN AS ONE OR (NORMALLY) MORE
"TASKS". ^THE TASK IS THE BASIC EXECUTABLE UNIT IN <MSX. ^A TASK RUNS
ON A SINGLE <CPU AND FORMS PART OF A PROGRAM BY COMMUNICATING, VIA
<MSX-11 DIRECTIVES, WITH OTHER TASKS ELSEWHERE IN THE SYSTEM. ^THE
CONCEPT "TASK" IS REFERRED TO AS "PROCESS" OR "PROGRAM" IN SOME SYSTEMS.
^HERE, A TASK IS THAT UNIT OF EXECUTABLE CODE THAT HAS A CONTEXT OF
REGISTERS, STACK, TRAP VECTORS, ETC. AND IS RUN AS A PROGRAM BY <MSX.
^ONE CONSTRUCTS APPLICATIONS OUT OF COMMUNICATING TASKS, WHICH MAY
SHARE MEMORY IF THE USER DESIRES OR COMMUNICATE VIA A SYSTEM-SUPPLIED
FACILITY. ^TASKS ARE EXECUTED IN A MEMORY MAPPED ENVIRONMENT. ^THIS
MEANS THAT A TASK CANNOT FORM A PHYSICAL ADDRESS; IT FORMS VIRTUAL
ADDRESSES WHICH ARE TRANSLATED BY HARDWARE INTO PHYSICAL ADDRESSES
ACCORDING TO <MSX ALLOCATION POLICY. ^THIS PERMITS <MSX TO ENCAPSULATE
TASKS RUNNING UNDER ITSELF AND TO ENSURE, GIVEN SUITABLE USAGE OF THE
HOOKS PROVIDED, THAT TASKS CANNOT PASS INFORMATION IN CHANNELS NOT
PERMITTED BY <MSX CLASSIFICATION POLICY.
^THE SYSTEM IS CONSTRUCTED TO FACILITATE EXTENSIONS TO ITS FUNCTIONALITY
BY ADDING "PRIVILEGED TASKS", AND USES SUCH TASKS FOR PROGRAM LOADING,
"WATCHDOG" AND ROUTING FUNCTIONS, AND BASIC FILE STRUCTURE MAINTENANCE.
(^NOTE THAT NOT ALL THESE FUNCTIONS ARE FULLY IMPLEMENTED AT PRESENT.)
^THE SYSTEM DOES NOT ADDRESS AS YET THE CREATION OF VIRTUAL OPERATING
SYSTEMS BY PERMITTING PROCESSES TO OCCUPY SUPERVISOR SPACE AS WELL
AS USER SPACE; HOWEVER, THIS WILL BE A COMPARATIVELY SIMPLE THING
TO ADDRESS SHOULD IT BECOME IMPORTANT. ^IT IS DESIGNED TO PERMIT
EMULATORS FOR THE <RT11 OPERATING SYSTEM TO BE USED AT PRESENT TO
ALLOW IMPORTATION OF A RICH SET OF TOOLS AS NEEDED.

.PARAGRAPH
^BECAUSE DEVELOPING DISTRIBUTED APPLICATIONS ON A DISTRIBUTED SYSTEM
IS DIFFICULT, <MSX CAN BE ASSEMBLED AS EITHER A STAND-ALONE EXECUTIVE,
OR AS AN EMULATED DISTRIBUTED SYSTEM RUNNING UNDER THE <DEC <RSX-11
OPERATING SYSTEM (OR WITH SOME RESTRICTIONS, UNDER <IAS). ^THIS MAKES
<MSX A SYSTEM EMULATOR AS WELL AS A SYSTEM. ^UNDER <RSX, A VAST,
POWERFUL SET OF PROGRAMMING TOOLS IS AVAILABLE (MANY FROM THE LARGE
AND ACTIVE USER COMMUNITY) TO AID DEVELOPMENT. ^THESE FACILITATE
PROGRAM CREATION. ^RUNNING <MSX IN A "VIRTUALLY DISTRIBUTED"
ENVIRONMENT UNDER <RSX ALLOWS INTERCONNECTION PROBLEMS TO BE
ISOLATED FROM LOGIC ERRORS AND PREMITS RAPID TURNAROUND. ^FINALLY,
WHEN <MSX IS RUN STAND-ALONE, IT INCLUDES AN INTEGRAL SYMBOLIC
DEBUGGER AS A SYSTEM DEBUGGING TOOL. ^BECAUSE <MSX IS A MAPPED
SYSTEM, THE <MSX KERNEL CAN HANDLE UP TO 4 MEGABYTES OF MEMORY ON
A SUITABLE MODEL <PDP11. ^ITS OWN USE OF CORE IS IN THE 16^K RANGE
SO THAT IT IS NOT EXCESSIVELY LARGE FOR ITS ENVIRONMENT. ^CERTAIN
DESIGN CHOICES IN <MSX (NOTABLY THE HANDLING OF MESSAGE DATA) HAVE
BEEN MADE WITH A VIEW TO GUARANTEEING TASK ENCAPSULATION AT THE
EXPENSE OF SPEED. ^IT SHOULD BE BORNE IN MIND BY THE SYSTEM DESIGNER
THEREFORE THAT IF A CRITICAL EXECUTION PATH USES INTERTASK MESSAGES
FOR CARRYING LARGE AMOUNTS OF DATA, PERFORMANCE COULD SUFFER
SOME DEGRADATION. ^IF SUCH DATA EXCHANGE IS NEEDED, COMMONS IN
MEMORY OR SPECIALIZED DEVICES TO PROVIDE AN INTERPROCESSOR <DMA
CHANNEL SHOULD BE INVESTIGATED. ^IN MOST PLACES, <MSX TRIES TO
BE REASONABLY EFFICIENT, WITHIN THE LIMITS IMPOSED BY THE PROCESSOR'S
ARCHITECTURE.
.PARAGRAPH
<MSX IS DESIGNED TO THAT THE SYSTEM'S DATABASE MAY BE SHARED AMONG
PROCESSORS IN COMMON MEMORY, OR ELSE DISTRIBUTED, AND SO THAT
VARIOUS SYSTEM INTERRCONNECTIONS ARE POSSIBLE. ^TO IMPLEMENT THIS
VERSATILITY, HOWEVER, IT HAS BEEN NECESSARY TO LEAVE SOME PARTS OF
THE SYSTEM OPEN TO USER AND USE-SPECIFIC MODIFICATION. ^THESE PARTS
ARE COLLECTED TOGETHER IN THE FILE NAMED "<MXCONN" AND THE PRESENTLY
DONE VERSIONS ARE FOR A SAMPLE CASE OF INTERCONNECTION, NAMELY, A
COMMON BUS. ^THE ROUTINES HERE ARE, NAMELY, THE LOWEST LEVEL PROCEDURES
FOR MESSAGE TRANSMISSION AND RECEPTION AND ROUTING. ^ALSO, <MSX SELECTS
A <CPU TO START A TASK ON DYNAMICALLY AT TASK STARTUP. ^SINCE THIS
POLICY MAY BE DIFFERENT FOR DIFFERENT APPLICATIONS, THE LOWEST LEVEL
OF THAT POLICY HAS BEEN LEFT TO THE USER AS WELL. ^THE POLICY
IMPLEMENTED FOR PURPOSES OF DEMONSTRATING <MSX SELECTS THAT <CPU
WITH THE FEWEST ACTIVE TASKS TO RUN ANOTHER TASK ON. ^IT IS ENVISIONED
THAT WHERE A SPAWNED TASK SHARES MEMORY WITH ITS PARENT, THIS WILL
FORCE SAME-<CPU ALLOCATION, AND SPAWNING MAY LEAD TO A PREFERENCE FOR
THE SAME <CPU. ^HOWEVER, OTHER POLICIES ARE POSSIBLE, SO THE
CONTROLS ARE MADE AVAILABLE TO USERS. ^IF OTHER ACTIVITY MEASURES
ARE GATHERED THAN NUMBERS OF TASKS, THESE MAY BE USED IN POLICY
DECISIONS TOO. ^THESE DECISIONS DEPEND ON THE INTERCONNECTIONS
TOPOLOGIES AND SPEEDS, AND ON THE APPLICATION, SO IT WAS THOUGHT
WISEST TO SEPARATE THEM FROM THE <MSX EXEC PER SE AND LEAVE THE
CHOICES OPEN. ^THE PRESENT VERSIONS OF THE LOGIC TOOK ABOUT 2 DAYS
TO BRING UP, AS AN ORDER OF MAGNITUDE OF THE DIFFICULTY INVOLVED.
.PARAGRAPH
^THE MEMORY-MAPPED ENVIRONMENT OF <MSX TASKS LEADS TO SOME CONSTRAINTS
ON WHAT CAN BE DONE WHERE IN THE SYSTEM. <MSX SUPPORTS TASKS BY
PROVIDING SERVICES INVOKED BY A <TRAP INSTRUCTION FOLLOWED BY A CODE
INDICATING WHAT SERVICES ARE TO BE PROVIDED. ^THIS INSTRUCTION PASSES
CONTROL TO THE <MSX KERNEL, WHICH INTERPRETS IT. ^THE KERNEL MAY
COMMUNICATE WITH ANY TASK, BUT TWO TASKS, UNLESS THEY SHARE SOME
MEMORY, MAY NOT DIRECTLY ACCESS EACH OTHER'S MEMORY ORDINARILY.
^THUS, MESSAGES ARE COPIED INTO EACH SPACE AS NEEDED, OR OUT OF IT
INTO KERNEL SPACE WHERE MANIPULATION IS TO BE DONE (SINCE CROSS-SPACE
OPERATIONS ARE SOMEWHAT RESTRICTED). ^ALL ^I/^O IS DONE VIA THE <MSX
KERNEL AND THERE MAPPED TO PHYSICAL MEMORY. ^THERE ARE ONLY A FEW
WORDS NEEDED TO DESCRIBE AN ^I/^O TRANSACTION, SO THE OVERHEAD
HERE IS SMALL. ^IN ORDER TO SIMPLIFY IT, AND ALSO OTHER CHECKS,
<MSX ALLOCATES MEMORY IN 4^K CHUNKS (THE SIZE OF ONE MAPPING
AREA) AND SO ALLOCATES TASK ADDRESSING THAT SOME PHYSICAL MEMORY
RESPONDS TO ANY ADDRESS A TASK CAN FORM (EVEN THOUGH THE SAME MEMORY
MAY RESPOND TO SEVERAL ADDRESSES). ^ALL ^I/^O MUST THEN BE DONE INSIDE
THESE 4^K AREAS, WHICH WILL BE ENFORCED BY ANY <DMA DEVICE HANDLERS.
^THESE HAVE ACCESS TO ALL TASK MEMORY MAPS AND CAN BREAK UP LARGER
REQUESTS AUTOMATICALLY.
.PARAGRAPH
^BECAUSE OF THE MAPPING ENVIRONMENT, SOME FILE SERVICES WILL HAVE TO BE
DONE IN USER MODE CODE, AND MESSAGES ARE SENT FROM ONE TASK TO ANOTHER
AND ACKNOWLEDGED BY SEMAPHORES. ^THEY ARE NOT PASSED ON, THOUGH A
RECIPIENT MAY CHOOSE TO RESEND THEM AS DESIRED, AND IS NOT OBLIGED
TO COPY THE MESSAGE INTERNALLY TO DO SO.

.PARAGRAPH
^TO ALLOW ERROR RECOVERY, IT IS GENERALLY TRUE THAT THERE IS NO SINGLE
PRESCRIPTION THAT WILL ALWAYS WORK. <MSX PROVIDES 2 PRIMITIVE
CAPABILITIES TO FACILITATE ERROR DETECTION AND RECOVERY, AND EXPECTS
WATCHDOG TASKS TO BE RUNNING TO DETECT DOWN <CPU'S. (<MSX PROVIDES
SOME TIMING FUNCTIONALITY FOR THEIR BENEFIT). ^THE FIRST PRIMITIVE IS
THAT <MSX SUPPORTS A TASK HIERARCHY. ^IF A CALLER TASK EXITS, ALL
TASKS IT CALLED ("SPAWNED") ARE FORCED TO EXIT BY THE SYSTEM. ^ALSO,
IF A CALLED TASK EXITS, THE CALLER IS NOTIFIED AND GIVEN (AT LEAST
IF HE HAS THE SAME CLASSIFICATION) A CODE FOR WHY THE EXIT OCCURRED.
^THE CALLER MAY SPECIFY AN ASYNCHRONOUS ENTRY WHERE HE WILL GAIN CONTROL
IF HE HAS TO EXIT, OR IF HIS SPAWNED TASK EXITS (2 ENTRIES, NOT 1).
^ALTERNATIVELY, HE MAY USE SEMAPHORE SIGNALS PROVIDED. ^IN EITHER
CASE, HE MAY RESTART THE SPAWNED TASKS IF APPROPRIATE, KNOWING
THAT ALL SUCCESSOR TASKS HAVE EXITED. ^THE ENTRY FOR HIS OWN EXIT
ALLOWS LAST-MINUTE CLEANUP (ONCE ONLY) OF ANY OPEN TRANSACTIONS. ^THIS
IS FOR CASES OF SHARED MEMORY, OPEN FILES, OR WHAT HAVE YOU THAT THE
SYSTEM CANNOT REASONABLY KEEP TRACK OF. ^THIS CLEANUP ENTRY IS THE SECOND
PRIMITIVE FOR ERROR CLEANUP. ^NOTE THAT THE <MSX SYSTEM DOES NOT NOW, BUT
WILL EVENTUALLY MAKE MESSAGES READ-ONLY OBJECTS TO THE TASKS USING
MAPPING HARDWARE. ^THESE MESSAGES ARE AVAILABLE IF THE <CPU IS STILL
UP WHERE THE DESTINATION TASK WAS RUNNING. ^OTHERWISE, MESSAGES MAY
BE EASILY KEPT AT THE SENDER TASKS BY ADDING (WITH AVAILABLE FACILITIES)
AN ADDITIONAL LEVEL OF ACKNOWLEDGEMENT AT MESSAGE PROCESSING COMPLETION.
(^THE SYSTEM NOTIFIES THE SENDER WHEN THE MESSAGE IS ENQUEUED AND
WHEN IT IS DEQUEUED BY THE RECEIVER; IT DOES NOT SPECIFICALLY TELL
THE SENDER WHEN THE MESSAGE IS FREED BY THE RECEIVER. ^SUCH PROTOCOLS
ARE LEFT TO THE USERS. ^A FORM OF WAIT IS PROVIDED THAT ALLOWS
A WAIT TO END IF THE TASK THAT SHOULD NORMALLY HAVE ENDED IT EXITS.
^THIS WILL ALSO AID DEADLOCK AVOIDANCE.