TempleOSCD_140715.ISO
This commit is contained in:
Terry A. Davis authored and minexew committed
1 parent
7ef616a20e
commit
64f679eeb9
1095 files changed
+24814
-221011
No files matched your search
+167
-175
@@ -1,180 +1,186 @@
|
||||
$WW,1$$TR,"Abbreviations"$
|
||||
$ID,2$$FG,5$Abs$FG$ Absolute
|
||||
$FG,5$Acct$FG$ Account
|
||||
$FG,5$Addr$FG$ Address
|
||||
$FG,5$AOT$FG$ Ahead-of-Time
|
||||
$FG,5$AP$FG$ Application Processor (CPU# > 0)
|
||||
$FG,5$Arg$FG$ Argument
|
||||
$FG,5$Attr$FG$ Attribute
|
||||
$FG,5$Aux$FG$ Auxilliary
|
||||
$FG,5$Blk$FG$ Block
|
||||
$FG,5$BSP$FG$ Boot-strap Processor (CPU#0)
|
||||
$FG,5$Buf$FG$ Buffer
|
||||
$FG,5$CB$FG$ Call-Back or Code Block
|
||||
$FG,5$Cfg$FG$ Config
|
||||
$FG,5$Chg$FG$ Change
|
||||
$FG,5$Chk$FG$ Check
|
||||
$FG,5$Const$FG$ Consant
|
||||
$FG,5$Cmd$FG$ Command
|
||||
$FG,5$Cmp$FG$ Compiler
|
||||
$FG,5$Cnt$FG$ Count
|
||||
$FG,5$Ctrl$FG$ Control. The ctrl key is indicated with "$FG,2$^$FG$" in documentation.
|
||||
$FG,5$Cur$FG$ Current
|
||||
$FG,5$Cvt$FG$ Convert
|
||||
$FG,5$Dbg$FG$ Debug
|
||||
$FG,5$Dbl$FG$ Double
|
||||
$FG,5$DC$FG$ Device Context
|
||||
$FG,5$Del$FG$ Delete
|
||||
$FG,5$Desc$FG$ Descriptor or Description
|
||||
$FG,5$Dev$FG$ Device
|
||||
$FG,5$Dft$FG$ Default
|
||||
$FG,5$Dir$FG$ Directory, Direction
|
||||
$FG,5$Doc$FG$ Document
|
||||
$FG,5$Drv$FG$ Drive
|
||||
$FG,5$Dsk$FG$ Disk
|
||||
$FG,5$Dst$FG$ Destination
|
||||
$FG,5$Ed$FG$ Edit, Editor
|
||||
$FG,5$Elem$FG$ Element
|
||||
$FG,5$Evt$FG$ Event
|
||||
$FG,5$Exe$FG$ Execute
|
||||
$FG,5$Ext$FG$ Extern or Extended
|
||||
$FG,5$Feat$FG$ Feature
|
||||
$FG,5$$FG,5$Fmt$FG$ Format
|
||||
$FG,5$Fwd$FG$ Forward
|
||||
$FG,5$fp_$FG$ Function ptr
|
||||
$FG,5$Fun$FG$ Function
|
||||
$FG,5$Gen$FG$ Generate
|
||||
$FG,5$Glbl$FG$ Global
|
||||
$FG,5$Gr$FG$ Graphic
|
||||
$FG,5$IDE$FG$ Integrated Drive Electronics, Integrated Development Environment
|
||||
$FG,5$Ident$FG$ Identifier, Identity
|
||||
$FG,5$IDT$FG$ Interrupt Descriptor Table
|
||||
$FG,5$Init$FG$ Initialize
|
||||
$FG,5$Ins$FG$ Insert
|
||||
$FG,5$Int$FG$ Interrupt
|
||||
$FG,5$ip_$FG$ Input Pointer. See $LK,"InputPointer.CPP",A="FI:::/Kernel/KbdMouse/InputPointer.CPP"$.
|
||||
$FG,5$Irq$FG$ Interrupt (Request)
|
||||
$FG,5$JIT$FG$ Just-in-Time
|
||||
$FG,5$Kbd$FG$ Keyboard
|
||||
$FG,5$KD$FG$ Keyboard Device
|
||||
$FG,5$Len$FG$ Length
|
||||
$FG,5$Let$FG$ Letter
|
||||
$FG,5$Lex$FG$ Lexical Analyser
|
||||
$FG,5$Loc$FG$ Location, Lines of Code
|
||||
$FG,5$Log$FG$ Logarithm or Logical
|
||||
$FG,5$Lst$FG$ List
|
||||
$FG,5$Man$FG$ Manual
|
||||
$FG,5$Mem$FG$ Memory
|
||||
$FG,5$Mgd$FG$ Managed
|
||||
$FG,5$Mgr$FG$ Manager
|
||||
$FG,5$Mon$FG$ Month
|
||||
$FG,5$MP$FG$ MultiProcessor
|
||||
$FG,5$Msg$FG$ Message
|
||||
$FG,5$Num$FG$ Number
|
||||
$FG,5$Obj$FG$ Object
|
||||
$FG,5$Occ$FG$ Occurrence
|
||||
$FG,5$CMathODE$FG$ Ordinary Differential Equation
|
||||
$FG,5$Paren$FG$ Parenthesis
|
||||
$FG,5$Pix$FG$ Pixel
|
||||
$FG,5$$FG,5$Pkg$FG$ Package
|
||||
$FG,5$Pmt$FG$ Prompt
|
||||
$FG,5$Poly$FG$ Polygon
|
||||
$FG,5$Pos$FG$ Position
|
||||
$FG,5$Prec$FG$ Precedence
|
||||
$FG,5$Prod$FG$ Product or Production
|
||||
$FG,5$Pri$FG$ Primary
|
||||
$FG,5$Prt$FG$ Partition
|
||||
$FG,5$Pt$FG$ Point
|
||||
$FG,5$Ptr$FG$ Pointer
|
||||
$FG,5$Que$FG$ Queue
|
||||
$FG,5$Reg$FG$ Register, Registry or Regular
|
||||
$FG,5$Rem$FG$ Remove
|
||||
$FG,5$Rep$FG$ Report
|
||||
$FG,5$Rqst$FG$ Request
|
||||
$FG,5$Rst$FG$ Reset
|
||||
$FG,5$Rot$FG$ Rotation
|
||||
$FG,5$Rx$FG$ Receive
|
||||
$FG,5$Sec$FG$ Second or Secondary
|
||||
$FG,5$$FG,5$Sect$FG$ Sector
|
||||
$FG,5$Seq$FG$ Sequence
|
||||
$FG,5$Snd$FG$ Sound
|
||||
$FG,5$Src$FG$ Source
|
||||
$FG,5$Srv$FG$ Servant
|
||||
$FG,5$Stat$FG$ Status or Statistic
|
||||
$FG,5$Std$FG$ Standard
|
||||
$FG,5$Stk$FG$ Stack
|
||||
$FG,5$Str$FG$ String
|
||||
$FG,5$Sym$FG$ Symbol
|
||||
$FG,5$Sys$FG$ System
|
||||
$FG,5$Term$FG$ Terminal
|
||||
$FG,5$Tri$FG$ Triangle
|
||||
$FG,5$Tx$FG$ Transmit
|
||||
$FG,5$Val$FG$ Value
|
||||
$FG,5$Var$FG$ Variable
|
||||
$FG,5$Vect$FG$ Vector
|
||||
$FG,5$Vol$FG$ Volume
|
||||
$FG,5$Win$FG$ Window
|
||||
$FG,5$Wiz$FG$ Wizard
|
||||
$FG,5$WS$FG$ WordStat
|
||||
$FG,5$WSD$FG$ WordStat Dictionary
|
||||
$WW,1$$FG,5$$TX+CX,"Glossery"$$FG$
|
||||
|
||||
$TR,"Abbreviations"$
|
||||
$ID,2$$FG,2$Abs$FG$ Absolute
|
||||
$FG,2$Acct$FG$ Account
|
||||
$FG,2$Addr$FG$ Address
|
||||
$FG,2$AOT$FG$ Ahead-of-Time
|
||||
$FG,2$AP$FG$ Application Processor(CPU#>0)
|
||||
$FG,2$Arg$FG$ Argument
|
||||
$FG,2$Asm$FG$ Assemble or Assembly
|
||||
$FG,2$Attr$FG$ Attribute
|
||||
$FG,2$Aux$FG$ Auxilliary
|
||||
$FG,2$BG$FG$ Backround
|
||||
$FG,2$Bin$FG$ Binary
|
||||
$FG,2$Blk$FG$ Block
|
||||
$FG,2$BSP$FG$ Boot-strap Processor(CPU#0)
|
||||
$FG,2$Buf$FG$ Buffer
|
||||
$FG,2$Bwd$FG$ Backward
|
||||
$FG,2$CB$FG$ Call-Back, Code Block
|
||||
$FG,2$Cfg$FG$ Config
|
||||
$FG,2$Chg$FG$ Change
|
||||
$FG,2$Chk$FG$ Check
|
||||
$FG,2$Const$FG$ Consant
|
||||
$FG,2$Cmd$FG$ Command
|
||||
$FG,2$Cmp$FG$ Compiler
|
||||
$FG,2$Cnt$FG$ Count
|
||||
$FG,2$Ctrl$FG$ Control. The ctrl key is indicated with "$FG,2$^$FG$" in documentation.
|
||||
$FG,2$Cur$FG$ Current
|
||||
$FG,2$Cvt$FG$ Convert
|
||||
$FG,2$Dbg$FG$ Debug
|
||||
$FG,2$Dbl$FG$ Double
|
||||
$FG,2$DC$FG$ Device Context
|
||||
$FG,2$Del$FG$ Delete
|
||||
$FG,2$Desc$FG$ Descriptor, Description
|
||||
$FG,2$Dev$FG$ Device
|
||||
$FG,2$Dft$FG$ Default
|
||||
$FG,2$Dir$FG$ Directory, Direction
|
||||
$FG,2$Doc$FG$ Document
|
||||
$FG,2$Drv$FG$ Drive
|
||||
$FG,2$Dsk$FG$ Disk
|
||||
$FG,2$Dst$FG$ Destination
|
||||
$FG,2$Ed$FG$ Edit, Editor
|
||||
$FG,2$Elem$FG$ Element
|
||||
$FG,2$Evt$FG$ Event
|
||||
$FG,2$Exe$FG$ Execute
|
||||
$FG,2$Ext$FG$ Extern, Extended
|
||||
$FG,2$Feat$FG$ Feature
|
||||
$FG,2$FG$FG$ Foreground
|
||||
$FG,2$Fmt$FG$ Format
|
||||
$FG,2$Fwd$FG$ Forward
|
||||
$FG,2$FPS$FG$ Frames per Second, First Person Shooter
|
||||
$FG,2$fp_$FG$ Function ptr
|
||||
$FG,2$Fun$FG$ Function
|
||||
$FG,2$Gen$FG$ Generate
|
||||
$FG,2$Glbl$FG$ Global
|
||||
$FG,2$Gr$FG$ Graphic
|
||||
$FG,2$IDE$FG$ Integrated Drive Electronics, Integrated Development Environment
|
||||
$FG,2$Ident$FG$ Identifier, Identity
|
||||
$FG,2$IDT$FG$ Interrupt Descriptor Table
|
||||
$FG,2$Init$FG$ Initialize
|
||||
$FG,2$Ins$FG$ Insert
|
||||
$FG,2$Int$FG$ Interrupt
|
||||
$FG,2$ip_$FG$ Input Pointer. See $LK,"InputPointer.CPP",A="FI:::/Kernel/KbdMouse/InputPointer.CPP"$.
|
||||
$FG,2$Irq$FG$ Interrupt (Request)
|
||||
$FG,2$JIT$FG$ Just-in-Time
|
||||
$FG,2$Kbd$FG$ Keyboard
|
||||
$FG,2$KD$FG$ Keyboard Device
|
||||
$FG,2$Len$FG$ Length
|
||||
$FG,2$Let$FG$ Letter
|
||||
$FG,2$Lex$FG$ Lexical Analyser
|
||||
$FG,2$Loc$FG$ Location, Lines of Code
|
||||
$FG,2$Log$FG$ Logarithm, Logical
|
||||
$FG,2$Lst$FG$ List
|
||||
$FG,2$Man$FG$ Manual
|
||||
$FG,2$Mem$FG$ Memory
|
||||
$FG,2$Mgd$FG$ Managed
|
||||
$FG,2$Mgr$FG$ Manager
|
||||
$FG,2$Mon$FG$ Month
|
||||
$FG,2$MP$FG$ MultiProcessor
|
||||
$FG,2$Msg$FG$ Message
|
||||
$FG,2$Num$FG$ Number
|
||||
$FG,2$Obj$FG$ Object
|
||||
$FG,2$Occ$FG$ Occurrence
|
||||
$FG,2$ODE$FG$ Ordinary Differential Equation
|
||||
$FG,2$Paren$FG$ Parenthesis
|
||||
$FG,2$Pix$FG$ Pixel
|
||||
$FG,2$$FG,2$Pkg$FG$ Package
|
||||
$FG,2$Poly$FG$ Polygon
|
||||
$FG,2$Pos$FG$ Position
|
||||
$FG,2$Prec$FG$ Precedence
|
||||
$FG,2$Pri$FG$ Primary
|
||||
$FG,2$Prod$FG$ Product, Production
|
||||
$FG,2$Prof$FG$ Profile, Profiler
|
||||
$FG,2$Prt$FG$ Partition
|
||||
$FG,2$PSect$FG$ Program Section
|
||||
$FG,2$Pt$FG$ Point
|
||||
$FG,2$Ptr$FG$ Pointer
|
||||
$FG,2$Que$FG$ Queue
|
||||
$FG,2$Ref$FG$ Reference
|
||||
$FG,2$Reg$FG$ Register, Registry, Regular
|
||||
$FG,2$Rem$FG$ Remove
|
||||
$FG,2$Rep$FG$ Report, Repeat
|
||||
$FG,2$Rqst$FG$ Request
|
||||
$FG,2$Rst$FG$ Reset
|
||||
$FG,2$Rot$FG$ Rotation
|
||||
$FG,2$Rx$FG$ Receive
|
||||
$FG,2$Sched$FG$ Sceduler
|
||||
$FG,2$Sec$FG$ Second, Secondary
|
||||
$FG,2$$FG,2$Sect$FG$ Sector
|
||||
$FG,2$Seq$FG$ Sequence
|
||||
$FG,2$Snd$FG$ Sound
|
||||
$FG,2$Src$FG$ Source
|
||||
$FG,2$Srv$FG$ Servant
|
||||
$FG,2$Stat$FG$ Status, Statistic
|
||||
$FG,2$Std$FG$ Standard
|
||||
$FG,2$Stk$FG$ Stack
|
||||
$FG,2$Str$FG$ String
|
||||
$FG,2$Sym$FG$ Symbol
|
||||
$FG,2$Sys$FG$ System
|
||||
$FG,2$Term$FG$ Terminal
|
||||
$FG,2$Tri$FG$ Triangle
|
||||
$FG,2$Tx$FG$ Transmit
|
||||
$FG,2$Uasm$FG$ Unassemble
|
||||
$FG,2$Val$FG$ Value
|
||||
$FG,2$Var$FG$ Variable
|
||||
$FG,2$Vect$FG$ Vector
|
||||
$FG,2$Vol$FG$ Volume
|
||||
$FG,2$Win$FG$ Window
|
||||
$FG,2$Wiz$FG$ Wizard
|
||||
$FG,2$WS$FG$ WordStat
|
||||
$FG,2$WSD$FG$ WordStat Dictionary
|
||||
$ID,-2$$TR,"Task/Process/Thread"$
|
||||
$ID,2$There is no distinction between "task", "process" or "thread." The $FG,2$Fs$FG$ segment reg is kept pointing to the current task's $LK,"CTask",A="MN:CTask"$. There is only one window per task.
|
||||
|
||||
$ID,2$There is no distinction between $FG,2$task$FG$, $FG,2$process$FG$ or $FG,2$thread$FG$. The $FG,2$Fs$FG$ segment reg is kept pointing to the current task's $LK,"CTask",A="MN:CTask"$. There is only one window per task, and only $FG,2$core#0$FG$ tasks can have windows. Each task has a code and data heap so memory is returned when it dies. Each task has a $LK,"hash",A="HI:Hash"$ symbol table.
|
||||
$ID,-2$$TR,"Adam Task"$
|
||||
$ID,2$This is Adam, as in Adam and Eve, the parent of all tasks. This task is created at start-up and appears in the small window at the top beneath the user windows. On it's heap are all memory objects which are system wide. When created, it runs the file $LK,"::/Kernel/Adam1.CPP"$ Normally, Adam1.CPP.Z ends by $FG,2$#include$FG$ $LK,"::/Adam/Adam2.CPP"$ where the remainder of the operating system is "$FG,2$#include$FG$d". When start-up is finished, the adam task enters a server mode where it accepts requests from other tasks. The $LK,"Adam",A="MN:Adam"$("") routine will cause the adam task to compile and run text src code. "$FG,2$#include$FG$" statements can be sent to the $LK,"Adam",A="MN:Adam"$("") routine, creating system-wide code and data which don't disappear when any particular task ends. (The Adam task is immortal.)
|
||||
|
||||
$ID,2$This is Adam, as in Adam and Eve, the parent of all tasks and immortal. This task is created at start-up and appears in the small window at the top beneath the user windows. On it's heap are all memory objects which you don't want destroyed by a task's death. When created, Adam runs the file $LK,"::/Kernel/Adam1.CPP"$ Normally, $FG,2$Adam1.CPP.Z$FG$ ends by $FG,2$#include$FG$ $LK,"::/Adam/Adam2.CPP"$ where the remainder of the operating system is $FG,2$#include$FG$d. When start-up is finished, the adam task enters a server mode where it accepts requests from other tasks. The $LK,"Adam",A="MN:Adam"$("") routine will make Adam compile and run text src code. $FG,2$#include$FG$ statements can be sent to $LK,"Adam",A="MN:Adam"$(""), creating system-wide code and data which don't disappear when any particular task ends.
|
||||
$ID,-2$$TR,"Seth Task"$
|
||||
$ID,2$This is Seth, as in Adam and Eve's child. Each CPU core has a special task which is immortal and which is special. The Adam task on CPU#0 is also it's Seth task.
|
||||
|
||||
$ID,2$$FG,2$Seth$FG$ is Adam and Eve's child. Each CPU core has a special task which is immortal and which is special. The Adam task on $FG,2$CPU#0$FG$ is also it's $FG,2$Seth$FG$ task.
|
||||
$ID,-2$$TR,"Code and Data Heaps"$
|
||||
$ID,2$TempleOS uses the asm $FG,2$CALL$FG$ instruction exclusively and it's limited to calling routines +/-2 Gig from the current code location. To prevent out-of-range issues, I decided to separate code and data, placing all code within the lowest 2 Gig of memory. The compiler and $LK,"Load",A="MN:Load"$()er allocate memory from the code heap to store code and glbl vars, unless the compiler option $LK,"OPTf_GLBLS_ON_DATA_HEAP",A="MN:OPTf_GLBLS_ON_DATA_HEAP"$ is used. When programs call $LK,"MAlloc",A="MN:MAlloc"$() is comes from the data heap, which in not limited in size, except by how much physical RAM memory you have. You can allocate from any heap you like, or even make independent heaps.
|
||||
|
||||
$ID,-2$$TR,"Parent/Child Task"$
|
||||
$ID,2$Often a task will $LK,"Spawn",A="MN:Spawn"$() or $LK,"PopUp",A="MN:PopUp"$() a task as a helper. The helper is known as a Child Task, though you can $FG,2$Spawn$FG$ a task and assign it a different parent... like $FG,2$Adam$FG$. Links are kept as to who spawned what so when one task is $LK,"Kill",A="MN:Kill"$()ed the helper tasks disappear, too. You can get a report on current system tasks with $LK,"TaskRep",A="MN:TaskRep"$(). There is just one possible window per task, so child tasks are needed.
|
||||
|
||||
$ID,2$TempleOS uses the asm $FG,2$CALL$FG$ instruction, exclusively, and that instruction is limited to calling routines $FG,2$+/-2 Gig$FG$ from the current code location. To prevent out-of-range issues, I decided to separate code and data, placing all code within the lowest $FG,2$2 Gig$FG$ of memory, addresses $FG,2$00000000$FG$-$FG,2$7FFFFFFF$FG$. The compiler and $LK,"Load",A="MN:Load"$()er allocate memory from the code heap to store code and glbl vars, unless the compiler option $LK,"OPTf_GLBLS_ON_DATA_HEAP",A="MN:OPTf_GLBLS_ON_DATA_HEAP"$ is used. When programs call $LK,"MAlloc",A="MN:MAlloc"$() is from the data heap, which in not limited in size, except by physical RAM memory. You can allocate from any heap in any task at any time on any core, even making $LK,"independent",A="MN:MemBlksIndependentAlloc"$ heaps.
|
||||
$ID,-2$$TR,"Parent, Child and PopUp Tasks"$
|
||||
$ID,2$Often a task will $LK,"Spawn",A="MN:Spawn"$() or $LK,"PopUp",A="MN:PopUp"$() a task as a helper. The helper is known as a child Task, though you can $LK,"Spawn",A="MN:Spawn"$ a task and assign it a different parent... like $FG,2$Adam$FG$. Links are kept as to who's who's child, so when one task is $LK,"Kill",A="MN:Kill"$()ed the child helper tasks die, too. You can get a report of current system tasks with $LK,"TaskRep",A="MN:TaskRep"$(). There is just one window per task, so child tasks are needed for pop-ups.
|
||||
$ID,-2$$TR,"HolyC"$
|
||||
$ID,2$$LK,"HolyC",A="FI:::/Doc/HolyC.TXT"$ is more than $FG,2$C$FG$ and less than $FG,2$C++$FG$. It has the default args of $FG,2$C++$FG$ and uses $FG,2$class$FG$ in place of $FG,2$struct$FG$. It uses $FG,2$U0,U8,U16,U32,I64$FG$ and $FG,2$I0,I8,I16,I32,I64$FG$ for signed and unsigned integers. It has different $LK,"operator precedence",A="FF:::/Doc/HolyC.TXT,operator precedence"$. It has $FG,2$PASCAL$FG$-like function calls with no parens, but requires an "$FG,2$&$FG,2$$FG$" when referring to function addresses.
|
||||
|
||||
$ID,2$$LK,"HolyC",A="FI:::/Doc/HolyC.TXT"$ is more than $FG,2$C$FG$ and less than $FG,2$C++$FG$. It has the default args of $FG,2$C++$FG$ and uses $FG,2$class$FG$ in place of $FG,2$struct$FG$. It uses $FG,2$U0,U8,U16,U32,I64$FG$ and $FG,2$I0,I8,I16,I32,I64$FG$ for signed and unsigned integers. It has different $LK,"operator precedence",A="FF:::/Doc/HolyC.TXT,operator precedence"$. It has $FG,2$PASCAL$FG$-like function calls with no parens, but requires an $FG,2$&$FG,2$$FG$ when referring to function addresses.
|
||||
$ID,-2$$TR,"AOT Compile Mode"$
|
||||
$ID,2$This term to refers to conventional compilation mode. It is not the preferred mode for this operating system and is discouraged. $FG,2$.PRJ$FG$ files are compiled to $FG,2$.BIN$FG$ files, skipping $FG,2$.OBJ$FG$ files. After compiling, you do a $LK,"Load",A="MN:Load"$() cmd which is available by right-clicking on a link (like from $LK,"Dir",A="MN:Dir"$()). There is no $FG,2$main()$FG$ routine. Instead, statements outside functions are automatically executed upon loading. There is no way to unload except by killing the task. To invoke $FG,2$AOT Compiled Mode$FG$, use the $LK,"Cmp",A="MN:Cmp"$() routine or right-click on a link. The $FG,2$Kernel$FG$ modules and compiler are made in $FG,2$AOT$FG$ compiled mode and stored in $FG,2$Kernel.BIN.C$FG$ and $FG,2$Compiler.BIN.Z$FG$, respectively.
|
||||
$ID,2$$FG,2$Ahead-of-Time$FG$ compiling is conventional compilation mode. Do not use $FG,2$AOT$FG$, use $FG,2$JIT$FG$ compiling.
|
||||
|
||||
See $LK,"::/Demo/Games/EagleDive.CPP"$ for an example of an $FG,2$AOT$FG$ module.
|
||||
In $FG,2$AOT$FG$ mode, $FG,2$.PRJ$FG$ files are compiled to $FG,2$.BIN$FG$ files, skipping $FG,2$.OBJ$FG$ files. After compiling, $FG,2$.BIN$FG$ files are $LK,"Load",A="MN:Load"$()ed.
|
||||
|
||||
There is no $FG,2$main()$FG$ routine. Instead, statements outside functions are automatically executed upon loading. There is no way to unload except by killing the task. To invoke $FG,2$AOT Compiled Mode$FG$, $LK,"Cmp",A="MN:Cmp"$() is used. The $FG,2$Kernel$FG$ module and compiler are made in $FG,2$AOT$FG$ compiled mode. See $LK,"MakeOSPrtBootInstall",A="MN:MakeOSPrtBootInstall"$() which calls $LK,"MakeAll",A="MN:MakeAll"$() where $FG,2$Kernel.BIN.C$FG$ and $FG,2$Compiler.BIN.Z$FG$ are created.
|
||||
$ID,-2$$TR,"JIT Compile Mode"$
|
||||
$ID,2$In just-in-time mode, the compiler allocates objects, code and data, from the heap, incrementally. This mode is used during cmd line operations. When you $FG,2$#include$FG$ a file, it is compiled function by function and objects are placed all over in mem. The $LK,"ExeFile",A="MN:ExeFile"$() routine is the same as $FG,2$#include$FG$ but can be placed in programs. $LK,"ExePrint",A="MN:ExePrint"$() routine will compile and run a string.
|
||||
|
||||
$ID,2$In $FG,2$just-in-time$FG$ mode, the compiler places code and data in memory allocated from the heap, incrementally, making them immediately ready for in-place execution. This mode is used during cmd line operations. When you $FG,2$#include$FG$ a file, it is compiled function by function and code ends-up all over in the memory, at least in the first 2Gig of memory. The $LK,"ExeFile",A="MN:ExeFile"$() routine is the same as $FG,2$#include$FG$ but can be used in programs. $LK,"ExePrint",A="MN:ExePrint"$() routine will compile and run a string.
|
||||
$ID,-2$$TR,"Compiler Intermediate Code"$
|
||||
$ID,2$The compiler generates instructions one step before making actual assembly (machine) language instructions. This code is reverse polish in nature and can be viewed with $LK,"OTrace",A="MN:OTrace"$(). The compiler does not "interpret" code, except in the process of optimization. The assembly language can be viewed when it is compiled with the $LK,"CTrace",A="MN:CTrace"$() routine, or afterward with $LK,"U",A="MN:U"$().
|
||||
|
||||
$ID,2$The compiler generates instructions one step before making actual assembly (machine) language instructions. This code is reverse polish stack machine in nature and can be viewed with $LK,"OTrace",A="MN:OTrace"$(). The compiler does not $FG,2$interpret$FG$ code, except in the process of optimization to make the final machine code. Assembly language output can be viewed when code is compiled with the $LK,"CTrace",A="MN:CTrace"$(), or, afterward, with $LK,"U",A="MN:U"$() or $LK,"Uf",A="MN:Uf"$("").
|
||||
$ID,-2$$TR,"Partition/Drive"$
|
||||
$ID,2$There is no distinction between "partition" or "drive." They are specified with a single letter from '$FG,2$A$FG$'-'$FG,2$Z$FG$'.
|
||||
$ID,2$There is no distinction between $FG,2$partition$FG$ or $FG,2$drive$FG$. They are specified with a single letter from $FG,2$A$FG$-$FG,2$Z$FG$.
|
||||
|
||||
'$FG,2$:$FG$' is the boot drive.
|
||||
|
||||
For commands taking a drive letter as an argument, $FG,2$0$FG$ is the current drive.
|
||||
|
||||
For commands taking a drive letter as an argument, char $FG,2$0$FG$ is the current drive.
|
||||
$ID,-2$$LK,"AutoFile",A="HI:AutoFile"$
|
||||
$LK,"Define",A="HI:Char/Define"$
|
||||
$LK,"Hash Table",A="HI:Hash"$
|
||||
$LK,"Bt, Bts, Btr, Btc, BEqu",A="HI:Bit"$
|
||||
$LK,"Define",A="HI:Define"$
|
||||
$LK,"DolDoc",A="FI:::/Doc/DolDocOverview.TXT"$
|
||||
$LK,"Editor Link Types",A="MN:LK_FILE"$
|
||||
$LK,"files_find_mask",A="FI:::/Doc/FileUtils.TXT"$
|
||||
$LK,"Hash Table",A="HI:Hash"$
|
||||
$LK,"RedSea File System",A="FI:::/Doc/RedSea.TXT"$
|
||||
$LK,"Sprite",A="HI:Graphics/Sprite"$
|
||||
$TR,"files_find_mask"$
|
||||
$ID,2$$LK,"FilesFindMatch",A="MN:FilesFindMatch"$(). An optional directory plus a list of filename masks, as in $FG,2$/Demo/*.TXT.Z;*.CPP.Z$FG$
|
||||
|
||||
See $LK,"FUF_RECURSE",A="MN:FUF_RECURSE"$, $LK,"ST_FILE_UTIL_FLAGS",A="MN:ST_FILE_UTIL_FLAGS"$, $LK,"FILEMASK_TXT",A="MN:FILEMASK_TXT"$, $LK,"FILEMASK_SRC",A="MN:FILEMASK_SRC"$, $LK,"FILEMASK_AOT",A="MN:FILEMASK_AOT"$, $LK,"FILEMASK_JIT",A="MN:FILEMASK_JIT"$, and $LK,"FILEMASK_GRA",A="MN:FILEMASK_GRA"$.
|
||||
|
||||
$TR,"CLI, STI, PUSHFD, POPFD"$
|
||||
$ID,2$These are x86 assembly instructions.
|
||||
$FG,2$CLI$FG$ disable interrupts.
|
||||
$FG,2$STI$FG$ enable interrupts.
|
||||
$FG,2$PUSHFD$FG$ pushes the CPU flags.
|
||||
$FG,2$POPFD$FG$ pops the CPU flags.
|
||||
$ID,-2$$TR,"Filename Extention Types"$
|
||||
$ID,2$
|
||||
$FG,5$*.???.Z$FG$
|
||||
$ID,2$$FG,5$*.???.Z$FG$
|
||||
These files are automatically compressed or uncompresses files when read or written.
|
||||
$FG,5$*.???.C$FG$
|
||||
Contiguous files--NOT compressed.
|
||||
$FG,5$*.TXT.Z;*.TXT;*.LOG.Z;*.LOG$FG$
|
||||
Text Files
|
||||
$FG,5$*.CPP.Z;*.CPP$FG$
|
||||
HolyC src files. The default HolyC compiler type is "$FG,2$.CPP.Z$FG$".
|
||||
HolyC src files. The default HolyC compiler type is $FG,2$.CPP.Z$FG$.
|
||||
$FG,5$*.PRJ.Z;*.PRJ$FG$
|
||||
HolyC src files to be compiled $FG,2$AOT$FG$.
|
||||
$FG,5$*.HPP.Z;*.HPP$FG$
|
||||
@@ -188,7 +194,7 @@ $FG,5$*.DAT.Z;*.DAT$FG$
|
||||
$FG,5$*.ISO$FG$
|
||||
CD-ROM image file--ISO9660.
|
||||
$FG,5$*.AUT.Z;*.AUT$FG$
|
||||
"AutoFile" Basically a HolyC program who's stdout goes to the input of a task when $LK,"AutoFile",A="MN:AutoFile"$() is called.
|
||||
$FG,2$AutoFile$FG$ Basically a HolyC program who's stdout goes to the input of a task when $LK,"AutoFile",A="MN:AutoFile"$() is called.
|
||||
$FG,5$*.GRA.Z;*.GRA$FG$
|
||||
Graphics file
|
||||
|
||||
@@ -197,9 +203,8 @@ $LK,"FILEMASK_SRC",A="MN:FILEMASK_SRC"$
|
||||
$LK,"FILEMASK_AOT",A="MN:FILEMASK_AOT"$
|
||||
$LK,"FILEMASK_JIT",A="MN:FILEMASK_JIT"$
|
||||
$LK,"FILEMASK_GRA",A="MN:FILEMASK_GRA"$
|
||||
|
||||
$ID,-2$$TR,"Naming Convention"$
|
||||
$ID,2$$FG,5$$FG$The following are rules I stick to. If you work on the operating system, it'd be good to stick with them for uniformity, but you can do what you like. Since there are no "$FG,2$namespaces$FG$" and I don't plan to implement name spaces, I highly recommend putting a 2-3 character module code prefix on syms. e.g. "WS","Doc","Lex"
|
||||
$ID,2$Since there are no $FG,2$namespaces$FG$ and I don't plan to implement name spaces, I highly recommend putting a 2-3 character module code prefix on syms. e.g. $FG,2$WS$FG$, $FG,2$Doc$FG$, $FG,2$Lex$FG$
|
||||
|
||||
$FG,5$ALL_CAPS$FG$
|
||||
Assembly Language labels are capitalized with underscores between words. So are $FG,2$#define$FG$'s.
|
||||
@@ -217,39 +222,26 @@ $FG,5$_lower_case$FG$
|
||||
Function args which are outputs (passed as ptrs) have leading underscores. Also, args which have identically named local variable counterparts have leading underscores.
|
||||
|
||||
$FG,5$DOCf_????$FG$
|
||||
Flags bit nums instead of bit values are designated with a lower case "$FG,2$f$FG$".
|
||||
Flags bit nums instead of bit values are designated with a lower case $FG,2$f$FG$.
|
||||
|
||||
$FG,5$DOCG_????$FG$
|
||||
Flag groups are designated with "$FG,2$G$FG$".
|
||||
|
||||
"$FG,5$result$FG$" is reserved for local variables that hold the function return val.
|
||||
|
||||
$FG,5$*$FG$ I used C++ like naming. I place "New", "Del", "Init", "Rst", ect. on the end of a function name instead of at the beginning. "$FG,2$RstMusicSettings$FG$" should be "$FG,2$MusicSettingsRst$FG$".
|
||||
$FG,5$result$FG$ is reserved for local variables that hold the function return val.
|
||||
|
||||
$FG,5$*$FG$ I used C++ like naming. I place $FG,2$New$FG$, $FG,2$Del$FG$, $FG,2$Init$FG$, $FG,2$Rst$FG$, ect. on the end of a function name instead of at the beginning. $FG,2$RstMusicSettings$FG$ should be $FG,2$MusicSettingsRst$FG$.
|
||||
$ID,-2$$TR,"Fs"$
|
||||
$ID,2$The CPU FS segment reg. This reg points to the current task's $LK,"CTask",A="MN:CTask"$.
|
||||
|
||||
$ID,-2$$TR,"Gs"$
|
||||
$ID,2$The CPU GS segment reg. This reg points to the $LK,"CCPU",A="MN:CCPU"$.
|
||||
|
||||
$ID,-2$$TR,"Bt,Bts,Btr,Btc,LBts,LBtr,LBtc"$
|
||||
$ID,2$These are bit manipulation functions named after x86 instructions. They stand for "Bit Test", "Bit Test and Set", "Bit Test and Reset" and "Bit Test and Compliment". An $FG,2$'L'$FG$ means locked with an ASM lock prefix.
|
||||
|
||||
$ID,-2$$TR,"Cli,Sti"$
|
||||
$ID,2$Turn on or off interrupts. They are named after the x86 instructions. "Cli" turns off interrupts.
|
||||
|
||||
$ID,2$The CPU GS segment reg. This reg points to the current core's $LK,"CCPU",A="MN:CCPU"$.
|
||||
$ID,-2$$TR,"Heap"$
|
||||
$ID,2$Programs can dynamically request chunks of memory allocated from a "heap" using $LK,"MAlloc",A="MN:MAlloc"$(). They must $LK,"Free",A="MN:Free"$() it when finished. Ptrs are used to refer to it. The "heap" is dynamically allocated mem.
|
||||
|
||||
$ID,2$Programs can dynamically request chunks of memory allocated from a $FG,2$heap$FG$ using $LK,"MAlloc",A="MN:MAlloc"$(). They must $LK,"Free",A="MN:Free"$() it when finished. Ptrs are used to refer to the chunk. The $FG,2$heap$FG$ is dynamically allocated mem.
|
||||
$ID,-2$$TR,"Root"$
|
||||
$ID,2$The base of a binary tree or the head of a queue is the root. (I don't like the word "head.")
|
||||
|
||||
$ID,2$The base of a binary tree or the head of a queue is the $FG,2$root$FG$. (I don't like the word $FG,2$head$FG$.)
|
||||
$ID,-2$$TR,"Join"$
|
||||
$ID,2$When two parts of a program have a common low-level routine, that routine is often labeled SomethingJoin.
|
||||
|
||||
$ID,-2$$TR,"user_data"$
|
||||
$ID,2$Many operating system structures have space set aside for you to store values. You are on your own managing these with multiple applications and libraries.
|
||||
|
||||
$ID,-2$$TR,"BSP/AP"$
|
||||
$ID,2$The "boot-strap processor" is core#0, has the Adam task, and is the master. The "application processors" have Seth tasks and are the slave processors. Only the BSP processor's tasks can have windows.
|
||||
$ID,-2$$TR,"Multicore BSP/AP Processors"$
|
||||
$ID,2$The $FG,2$boot-strap processor$FG$ is core#0, has the $FG,2$Adam task$FG$, and it is the master. The $FG,2$application processors$FG$ have Seth tasks and are the slave processors. Only the $FG,2$BSP$FG$ core#0 processor's tasks can have windows. More or less, applications are launched exclusively from the $FG,2$BSP$FG$ processor. It is the master. The only way slave cores get used is if the application explicitly $LK,"Spawn",A="MN:Spawn"$s() a task on them or $LK,"JobQue",A="MN:JobQue"$() a job on them.
|
||||
$ID,-2$
|
||||
Reference in new issue
Block a user