TempleOSCDV4.01.ISO

This commit is contained in:
Terry A. Davis authored and minexew committed 2018-09-08 21:46:47 +02:00
1 parent 0e0592d9a6
commit fedf66361e
85 files changed
+2463 -2376

No files matched your search

+47
View File
@@ -0,0 +1,47 @@
$WW,1$$FG,5$$TX+CX,"Assembler"$$FG$
See $LK,"::/Compiler/OpCodes.TXT"$ for opcodes. They're not standard. Some invalid instructions are not flagged and some valid instructions are not implemented. 16-bit asm support is limited.
Here are example instruction formats:
$HL,1$ ADD RAX,I64 FS:DISP[RSI+RDI*8]
$HL,0$$HL,1$ ADD RAX,I64 [DISP]
$HL,0$
$FG,2$$$$FG$ Current compiler output pos (instruction ptr). Even works in HolyC expressions.
$FG,2$$$$FG$ works in $FG,2$class$FG$es.
$FG,2$class MyFun
{
$$=-16;
I64 local1;
I64 local2;
$$=$$+256;
I64 crazy;
};$FG$
$FG,4$LABEL$FG,2$::
$FG$ Defines an exported glbl label.
$FG,4$LABEL$FG,2$:
$FG$ Defines an non-exported glbl label.
$FG,2$@@$FG,4$LABEL$FG,2$:
$FG$ Defines a local label with scope valid between two global labels.
$FG,2$DU8$FG$, $FG,2$DU16$FG$, $FG,2$DU32$FG$, $FG,2$DU64$FG$
Define BYTE, WORD, DWORD or QWORD. Can be used with $FG,2$DUP()$FG$ and ASCII strings. For your convenience, the ASCII strings do not have terminating zeros. Define cmds must end with a semicolon.
$FG,2$USE16$FG$, $FG,2$USE32$FG$, $FG,2$USE64$FG$
$FG,2$IMPORT$FG$ $FG,4$sym1name$FG$, $FG,4$sym2name$FG$;
$FG,2$LIST$FG$, $FG,2$NOLIST$FG$
$FG,2$ALIGN$FG$ $FG,4$num$FG$, $FG,4$fill_byte$FG$
Align to $FG,4$num$FG$ boundary and fill with $FG,4$fill_byte$FG$.
$FG,2$MODULE_ORG$FG$ $FG,4$num$FG$
Set code addr for JIT or set module $LK,"Load",A="MN:Load"$() addr -- has 16-byte $LK,"CBinFile",A="MN:CBinFile"$ header and patch table trailing.
$FG,2$BINFILE$FG,4$ "FileName.BIN"$FG$;
See $LK,"Assembly Language",A="FF:::/Doc/GuideLines.TXT,Assembly Language"$, $LK,"::/Demo/Asm/AsmAndC1.CPP"$, $LK,"::/Demo/Asm/AsmAndC2.CPP"$ and $LK,"::/Demo/Asm/AsmAndC3.CPP"$.
+22 -2
View File
@@ -2,8 +2,28 @@
Use $LK,"R",A="MN:R"$() to rename if I change a label.
$IV,1$----01/03/16 16:30:56----$IV,0$
* Updated $LK,"::/Misc/PCIDevices.TXT.Z"$.
$IV,1$----01/12/16 16:47:54----$IV,0$
* Overhauled $LK,"Mount",A="MN:Mount"$() and $LK,"::/Kernel/KCfg.CPP"$.
$IV,1$----01/12/16 10:06:18----$IV,0$
* $BK,1$TempleOS version 4.01 Released$BK,0$
* Standardized drive letters. Your $LK,"Auto",A="MN:Auto"$() config scripts for compiling the kernel with $LK,"MakeOSDrvBootInstall",A="MN:MakeOSDrvBootInstall"$() must be changed.
* Added $LK,"CCF_QUESTION_HELP",A="MN:CCF_QUESTION_HELP"$.
$IV,1$----01/11/16 00:04:38----$IV,0$
* $LK,"R",A="MN:R"$("PAGE_SIZE","MEM_PAGE_SIZE"); etc.
* $LK,"R",A="MN:R"$("DFT_STK","MEM_DFT_STK"); etc.
* Added $LK,"::/Demo/MemDemo.CPP"$.
$IV,1$----01/08/16 17:04:58----$IV,0$
* Added $LK,"FUF_RISKY",A="MN:FUF_RISKY"$ to $LK,"DocOpt",A="MN:DocOpt"$().
* Fixed $LK,"::/Doc/CompilerOverview.TXT"$.
$IV,1$----01/06/16 11:01:57----$IV,0$
* Got rid of $FG,4$DOCEF_HARD_SKIP$FG$.
$IV,1$----01/03/16 17:15:41----$IV,0$
* Updated $LK,"::/Misc/PCIDevices.TXT"$.
* Added null case option. Next higher integer with "$FG,2$case:$FG$" in $FG,2$switch$FG$ statements. See $LK,"::/Demo/NullCase.CPP"$.
$IV,1$----12/31/15 00:44:44----$IV,0$
+7 -86
View File
@@ -1,92 +1,13 @@
$WW,1$$FG,5$$TX+CX,"Compiler Directives"$$FG$
$WW,1$$FG,5$$TX+CX,"Compiler Index"$$FG$
The compiler looks-ahead a token most of the time, so you might throw an extra semicolon after the directive if it's not taking affect right away.
$LK,"::/Doc/Asm.TXT"$
$FG,2$#include ""$FG$ There is no angle bracket <> form of this directive.
$FG,2$#exe {}$FG$ Will execute code at compile-time and can be used to insert code into the stream being compiled using $LK,"StreamPrint",A="MN:StreamPrint"$().
$FG,2$#define$FG$ Define string const
$FG,2$#assert$FG$ Print a warning during compilation if an expression is not true.
$FG,2$#if$FG$ Include code if an expresion is true.
$FG,2$#else
#endif
#ifdef,#ifndef $FG$Include code if a sym is defined.
$FG,2$#ifaot,#ifjit $FG$Include code if in $FG,2$AOT$FG$ compiler mode.
$FG,2$defined()$FG$ Is a function that can be used in expressions.
$FG,2$#help_index$FG$, $FG,2$#help_file$FG$ See $LK,"Help System",A="FI:::/Doc/HelpSystem.TXT"$.
$HL,1$$WW,0$
#define __DATE__ #exe{StreamPrint("\"%D\"",Now);}
#define __TIME__ #exe{StreamPrint("\"%T\"",Now);}
#define __LINE__ #exe{StreamPrint("%d",Fs->last_lex->lex_include_stk->line_num);}
#define __DEPTH__ #exe{StreamPrint("%d",Fs->last_lex->lex_include_stk->depth);}
#define __FILE__ #exe{StreamPrint("\"%s\"",Fs->last_lex->lex_include_stk->full_name);}
#define __DIR__ #exe{StreamDir;}
$HL,0$$WW,1$
See $LK,"::/Demo/Directives.CPP"$, $LK,"Scoping and Linkages",A="FI:::/Doc/ImportExports.TXT"$, and $LK,"preprocessor",A="FF:::/Compiler/Lex.CPP,KW_DEFINE"$.
$LK,"::/Doc/Directives.TXT"$
$LK,"::/Doc/Options.TXT"$
$FG,5$$TX+CX,"Compiler Options"$$FG$
$LK,"::/Doc/PreProcessor.TXT"$
Use $LK,"Option",A="MN:Option"$(). You might need to do $FG,2$#exe {Option();}$FG$.
$LK,"::/Doc/ScopingLinkage.TXT"$
$LK,"OPTf_GLBLS_ON_DATA_HEAP",A="MN:OPTf_GLBLS_ON_DATA_HEAP"$ without this option, global vars are placed in the code heap which is limited to 2 Gig. In $FG,2$AOT$FG$ modules, global vars take-up room in the $FG,2$.BIN$FG$ file, so you might want to use this option, instead. You might wish to turn it on and off around specific vars. A disadvantage of data heap global vars in $FG,2$AOT$FG$ modules is they can't be initialized.
$LK,"OPTf_EXTERNS_TO_IMPORTS",A="MN:OPTf_EXTERNS_TO_IMPORTS"$ and $LK,"OPTf_KEEP_PRIVATE",A="MN:OPTf_KEEP_PRIVATE"$ are strange options, you'll never need. They're to allow the same header file for $FG,2$Kernel$FG$ to act as $FG,2$extern$FG$s when compiling itself and $FG,2$import$FG$s when compiled by $FG,2$AOT$FG$ modules.
$LK,"OPTf_WARN_UNUSED_VAR",A="MN:OPTf_WARN_UNUSED_VAR"$ warning if unused var. It is applied to functions.
$LK,"OPTf_WARN_PAREN",A="MN:OPTf_WARN_PAREN"$ warning if parenthesis are not needed.
$LK,"OPTf_WARN_DUP_TYPES",A="MN:OPTf_WARN_DUP_TYPES"$ warning if dup local var type statements.
$LK,"OPTf_NO_REG_VAR",A="MN:OPTf_NO_REG_VAR"$ forces all function local vars to the stk not regs. Applied to functions.
$LK,"OPTf_NO_BUILTIN_CONST",A="MN:OPTf_NO_BUILTIN_CONST"$ Disable 10-byte float consts for ã, log2_10, log10_2, loge_2. Applied to functions.
$FG,5$$TX+CX,"Assembler Directives"$$FG$
See $LK,"::/Compiler/OpCodes.TXT"$ for opcodes. They're not standard. Some invalid instructions are not flagged and some valid instructions are not implemented. 16-bit asm support is limited.
Here are example instruction formats:
$HL,1$ ADD RAX,I64 FS:DISP[RSI+RDI*8]
$HL,0$$HL,1$ ADD RAX,I64 [DISP]
$HL,0$
$FG,2$$$$FG$ Current compiler output pos (instruction ptr). Even works in HolyC expressions.
$FG,2$$$$FG$ works in $FG,2$class$FG$es.
$FG,2$class MyFun
{
$$=-16;
I64 local1;
I64 local2;
$$=$$+256;
I64 crazy;
};$FG$
$FG,4$LABEL$FG,2$::
$FG$ Defines an exported glbl label.
$FG,4$LABEL$FG,2$:
$FG$ Defines an non-exported glbl label.
$FG,2$@@$FG,4$LABEL$FG,2$:
$FG$ Defines a local label with scope valid between two global labels.
$FG,2$DU8$FG$, $FG,2$DU16$FG$, $FG,2$DU32$FG$, $FG,2$DU64$FG$
Define BYTE, WORD, DWORD or QWORD. Can be used with $FG,2$DUP()$FG$ and ASCII strings. For your convenience, the ASCII strings do not have terminating zeros. Define cmds must end with a semicolon.
$FG,2$USE16$FG$, $FG,2$USE32$FG$, $FG,2$USE64$FG$
$FG,2$IMPORT$FG$ $FG,4$sym1name$FG$, $FG,4$sym2name$FG$;
$FG,2$LIST$FG$, $FG,2$NOLIST$FG$
$FG,2$ALIGN$FG$ $FG,4$num$FG$, $FG,4$fill_byte$FG$
Align to $FG,4$num$FG$ boundary and fill with $FG,4$fill_byte$FG$.
$FG,2$MODULE_ORG$FG$ $FG,4$num$FG$
Set code addr for JIT or set module $LK,"Load",A="MN:Load"$() addr -- has 16-byte $LK,"CBinFile",A="MN:CBinFile"$ header and patch table trailing.
$FG,2$BINFILE$FG,4$ "FileName.BIN"$FG$;
See $LK,"::/Demo/Asm/AsmAndC1.CPP"$, $LK,"::/Demo/Asm/AsmAndC2.CPP"$ and $LK,"::/Demo/Asm/AsmAndC3.CPP"$.
See $LK,"Hello World",A="FI:::/Doc/HelloWorld.TXT"$.
+1 -1
View File
@@ -22,7 +22,7 @@ $WW,1$$FG,5$$TX+CX,"Debugging Overview"$$FG$
* $LK,"Prof",A="MN:Prof"$() and $LK,"ProfRep",A="MN:ProfRep"$() provide code profiling. See $LK,"::/Demo/AutoFile/AFProfile.AUT"$ (This is an $LK,"AutoFile",A="FF:::/Doc/Glossary.TXT,AutoFile"$.)
* Use $LK,"RawPrint",A="MN:RawPrint"$() to print debug info bypassing the window framework. You pass these routines a count in milliseconds for how long it should be displayed. You can use $LK,"Raw",A="MN:Raw"$($FG,2$TRUE$FG$) to make all output bypass the window framework. The WinMgr runs on core0 and will overwrite raw text from other cores when it updates the screen.
* Use $LK,"RawPrint",A="MN:RawPrint"$() to print debug info bypassing the window framework. You pass these routines a count in milliseconds for how long it should be displayed. You can use $LK,"Raw",A="MN:Raw"$($FG,2$TRUE$FG$) to make all output bypass the window framework. The $FG,2$WinMgr$FG$ runs on $FG,2$core0$FG$ and will overwrite raw text from other cores when it updates the screen.
* Use $LK,"SysDbg",A="MN:SysDbg"$() to set a flag which you can read with $LK,"IsSysDbg",A="MN:IsSysDbg"$() when you wish to trigger some debug activity. It's just a handy simple flag, nothing fancy.
+1
View File
@@ -165,6 +165,7 @@ $LK,"::/Demo/DolDoc/ClickCallBack.CPP"$
$LK,"::/Demo/DolDoc/TreeDemo.CPP"$
$LK,"::/Demo/Exceptions.CPP"$
$LK,"::/Demo/Dsk/SerializeTree.CPP"$
$LK,"::/Demo/MemDemo.CPP"$
$LK,"::/Demo/StkGrow.CPP"$
$LK,"::/Demo/DolDoc/TextDemo.CPP"$
$LK,"::/Demo/DolDoc/CursorMove.CPP"$
+4 -4
View File
@@ -13,7 +13,7 @@ $FG,2$<CTRL-v> or <SHIFT-INS>$FG$
$ID,2$Paste clipboard.
$ID,-2$
$FG,2$LEFT-CLICK,drag-drop$FG$
$ID,2$Move a file or tree to a directory.
$ID,2$Move a file or tree to a dir.
$ID,-2$
$FG,2$LEFT-CLICK,same file or <SPACE>$FG$
$ID,2$Edit file.
@@ -34,7 +34,7 @@ $FG,2$'r'$FG$
$ID,2$Rename file.
$ID,-2$
$FG,2$'d'$FG$
$ID,2$Make Directory.
$ID,2$Make Dir.
$ID,-2$
$FG,2$'m'$FG$
$ID,2$ChgDsk (Remount removable media). Do not do this on blank disks.
@@ -43,7 +43,7 @@ $FG,2$'f'$FG$
$ID,2$Format drive.
$ID,-2$
$FG,2$'M'$FG$
$ID,2$Make CD/DVD ISO file. This creates a file image of the directory the cursor is on. The name of the ISO file is $LK,"blkdev.dft_iso_filename",A="MN:CBlkDevGlbls"$ and can be redefined in your start-up scripts. You may wish to place it on a different drive.
$ID,2$Make CD/DVD ISO file. This creates a file image of the dir the cursor is on. The name of the ISO file is $LK,"blkdev.dft_iso_filename",A="MN:CBlkDevGlbls"$ and can be redefined in your start-up scripts. You may wish to place it on a different drive.
$ID,-2$
$FG,2$'B'$FG$
$ID,2$Burn CD/DVD ISO file. This burns a CD/DVD using the image file, $LK,"blkdev.dft_iso_filename",A="MN:CBlkDevGlbls"$ to the drive the cursor is on.
@@ -54,7 +54,7 @@ $ID,2$If you have not recompiled Kernel and defined your CD/DVD drive, exit the
$ID,-2$
$FG,5$Instructions on Burning CD/DVD's$FG$
$ID,2$Create a temporary holding drive in RAM or on disk, copy files into the holding drive. Make an ISO image of the drive by pressing $FG,2$'M'$FG$ when on top of the holding drive. Press $FG,2$'B'$FG$ when on top of the CD/DVD ROM drive to burn the ISO to disk. If you have not recompiled $FG,2$Kernel$FG$ and defined your CD/DVD drive, exit the file mgr and use $LK,"Mount",A="MN:Mount"$.
$ID,2$Create a temporary dir to hold files and copy files into the holding dir. Make an ISO image of the dir by pressing $FG,2$'M'$FG$ when on top of the dir. Press $FG,2$'B'$FG$ when on top of the CD/DVD ROM drive to burn the ISO, $LK,"blkdev.dft_iso_filename",A="MN:CBlkDevGlbls"$, to disk. If you have not recompiled $FG,2$Kernel$FG$ and defined your CD/DVD drive, exit the file mgr and use $LK,"Mount",A="MN:Mount"$.
$LK,"Making Your Own Distro",A="FI:::/Misc/DoDistro.CPP"$
$ID,-2$
+3 -3
View File
@@ -140,11 +140,11 @@ $FG,2$Vol$FG$ Volume
$FG,2$Win$FG$ Window
$FG,2$Wiz$FG$ Wizard
$ID,-2$$TR,"Task/Process/Thread"$
$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$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$core0$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 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,"::/StartOS.CPP"$. 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$$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$$FG,2$Seth$FG$ is Adam and Eve's child. Each CPU core has an executive task called $FG,2$Seth$FG$ that is immortal. 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 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 alloc 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 alloc from any heap in any task at any time on any core, even making $LK,"independent",A="MN:Mem512Alloc"$ heaps.
$ID,-2$$TR,"Parent, Child and PopUp Tasks"$
@@ -253,5 +253,5 @@ $ID,2$When two parts of a program have a common low-level routine, that routine
$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,"Multicore Core0/CoreAP"$
$ID,2$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 core#0 tasks can have windows and can launch applications. Slave cores are used if the application explicitly $LK,"Spawn",A="MN:Spawn"$s() a task or $LK,"JobQue",A="MN:JobQue"$() a job on them.
$ID,2$Core0, has the $FG,2$Adam task$FG$, and it is the master. The $FG,2$application processors$FG$ have an executive $FG,2$Seth tasks$FG$ and are the slave processors. Only $FG,2$core0$FG$ tasks can have windows and can launch applications. Slave cores are used if the application explicitly $LK,"Spawn",A="MN:Spawn"$s() a task or $LK,"JobQue",A="MN:JobQue"$() a job on them.
$ID,-2$
+2
View File
@@ -106,6 +106,8 @@ $FG,5$$TX+CX,"Hash Sym Tables"$$FG$
$FG,5$$TX+CX,"Assembly Language"$$FG$
See $LK,"::/Doc/Asm.TXT"$.
* $FG,2$FS$FG$ must always point to the cur $LK,"CTask",A="MN:CTask"$.
* $FG,2$GS$FG$ must always point to the cur $LK,"CCPU",A="MN:CCPU"$.
BIN
View File
Binary file not shown.
+3 -3
View File
@@ -1,9 +1,9 @@
$WW,1$$FG,5$$TX+CX,"HolyC"$$FG$
* See $LK,"Scoping and Linkages",A="FI:::/Doc/ImportExports.TXT"$ for details on $FG,2$extern$FG$, $FG,2$import$FG$, $FG,2$_extern$FG$, $FG,2$_import$FG$, etc.
* See $LK,"::/Doc/CompilerOverview.TXT"$.
* See $LK,"Scoping and Linkage",A="FI:::/Doc/ScopingLinkage.TXT"$ for details on $FG,2$extern$FG$, $FG,2$import$FG$, $FG,2$_extern$FG$, $FG,2$_import$FG$, etc.
* Built-in types include $FG,2$I0,I8,I16,I32,I64$FG$ for signed 0-8 byte ints and $FG,2$U0,U8,U16,U32,U64$FG$ for unsigned 0-8 byte ints and $FG,2$F64$FG$ for 8 byte floats.
$FG,2$ U0 void, but ZERO size!
@@ -239,7 +239,7 @@ $FG$$ID,-2$
* You can $LK,"Free",A="MN:Free"$() a $FG,2$NULL$FG$ ptr. Useful variants of $LK,"MAlloc",A="MN:MAlloc"$() can be found $LK,"Here",A="MN:CAlloc"$. Each task has a heap and you can $FG,2$MAlloc$FG$ and $FG,2$Free$FG$ off of other task's heaps, or make an independent heap with $LK,"HeapCtrlBPInit",A="MN:HeapCtrlBPInit"$().
* The stk does not grow because virtual mem is not used. I recommend allocating large local vars from the heap. You can change $LK,"DFT_STK",A="MN:DFT_STK"$ and recompile $FG,2$Kernel$FG$ or request more when doing a $LK,"Spawn",A="MN:Spawn"$(). You can use $LK,"CallStkGrow",A="MN:CallStkGrow"$(), but it's odd. See $LK,"::/Demo/StkGrow.CPP"$.
* The stk does not grow because virtual mem is not used. I recommend allocating large local vars from the heap. You can change $LK,"MEM_DFT_STK",A="MN:MEM_DFT_STK"$ and recompile $FG,2$Kernel$FG$ or request more when doing a $LK,"Spawn",A="MN:Spawn"$(). You can use $LK,"CallStkGrow",A="MN:CallStkGrow"$(), but it's odd. See $LK,"::/Demo/StkGrow.CPP"$.
* Only one base class is allowed.
-120
View File
@@ -1,120 +0,0 @@
$FG,5$$TX+CX,"Details of Scoping and Linkages"$$FG$
$WW,1$
$LK,"JIT Compile Mode",A="FF:::/Doc/Glossary.TXT,JIT Compile Mode"$ makes use of the current task's hash sym table and its parent tasks' tables. It fetches syms from parent tasks' tables if not found locally in the current task's table and it places new syms in the current task's table. Conceptually, syms are at the scope of environment vars in other operating systems.
When a sym is placed into a table, older syms with identical names will be overshadowed if they exist. Duplicates are not allowed in many cases, especially in asm blks. Dupicates are allowed, by design in other cases, so that you can repeatedly $FG,2$#include$FG$ the same file from the cmd line while developing it. Or, so you can repeatedly declare a function with a standard name, like $FG,2$DrawIt()$FG$. This case might occur when the $FG,2$adam task$FG$ is starting-up loading-in many little utilities.
$FG,2$extern$FG$ binds a new $LK,"HTT_FUN",A="MN:HTT_FUN"$ or $LK,"HTT_GLBL_VAR",A="MN:HTT_GLBL_VAR"$ sym to an existing sym of the same name if it exists in the sym table (just in just-in-time code). It also can be used to generate a fwd reference.
$FG,2$import$FG$ binds a new $LK,"HTT_FUN",A="MN:HTT_FUN"$ or $LK,"HTT_GLBL_VAR",A="MN:HTT_GLBL_VAR"$ sym to a sym of the same name imported from the task's sym table at $LK,"Load",A="MN:Load"$() time. If no sym exists to bind to at $LK,"Load",A="MN:Load"$() time, the code using this sym will be left incomplete until the sym is defined.
$WW,1$
$FG,2$_extern$FG$ binds a new $LK,"HTT_FUN",A="MN:HTT_FUN"$ or $LK,"HTT_GLBL_VAR",A="MN:HTT_GLBL_VAR"$ sym to an existing sym, of a $BK,1$different$BK,0$ name. It must exists in the sym table. Basically, this binds C to asm.
$FG,2$_import$FG$ binds a new $LK,"HTT_FUN",A="MN:HTT_FUN"$ or $LK,"HTT_GLBL_VAR",A="MN:HTT_GLBL_VAR"$ sym to a sym, of a $BK,1$different$BK,0$ name imported from the task's sym table at $LK,"Load",A="MN:Load"$() time. If no sym exists to bind to at $LK,"Load",A="MN:Load"$() time, the code using this sym will be left incomplete until the sym is defined. Basically, this binds C to asm from elsewhere.
$WW,0$$FG,5$Ahead of Time Compilation$FG$
$FG,2$G$FG$lobalScope/$FG,2$F$FG$unctionScope
| $FG,2$C$FG$odeHeap/$FG,2$D$FG$ataHeap/$FG,2$S$FG$tack/$FG,2$R$FG$egister
| | TaskHashEntry:Export$FG,2$S$FG$ysSym/$FG,2$D$FG$efine/$FG,2$F$FG$unction/$FG,2$C$FG$lass
| | | UsageScope: $FG,2$M$FG$odule/$FG,2$A$FG$smLocal/Asm$FG,2$B$FG$lk/$FG,2$T$FG$askAndChildren/$FG,2$F$FG$unction
| | | |UsageScope: $FG,2$G$FG$lbl/Asm$FG,2$L$FG$ocal/$FG,2$R$FG$emainder/$FG,2$g$FG$lblThisBlkAndRemainder
| | | || $FG,2$S$FG$taticVarInit/$FG,2$D$FG$ynamicVarInitAllowed/$FG,2$N$FG$oInitAllowed
| | | || | Are dups allowed within the namespace? A dup overshadows the original.
| | | || | $FG,2$D$FG$upsAllowed/$FG,2$N$FG$oDups/NoDupsBut$FG,2$P$FG$ad/$FG,2$W$FG$arningUnlessClosedOut
asm export $FG,2$label::$FG$ G C S MG N
asm $FG,2$label:$FG$ G C MG N
asm local $FG,2$@@label:$FG$ G C AL N
asm $FG,2$IMPORT label;$FG$ G C MR N
asm export $FG,2$label::$FG$ F C S BG N
asm $FG,2$label:$FG$ F C BG N
asm local $FG,2$@@label:$FG$ F C AL N
asm $FG,2$IMPORT label;$FG$ F C BR N
C goto $FG,2$label:$FG$ F C FG N
$FG,2$#define$FG$ x MR D
function G C S MR D
var F R FR N
var F S FR N
$FG,2$static$FG$ var F C FR D N
var G C S MR D D
var G D MR N D
$FG,2$class$FG$ G MR D
class member G MR P
$FG,2$extern class$FG$ G MR D
$FG,2$extern$FG$ function G C MR W
$FG,2$import$FG$ function G C MR D
$FG,2$import$FG$ var G C MR D
$FG,2$_extern$FG$ function G C MR D
$FG,2$_extern$FG$ var G C MR D
$FG,2$_import$FG$ function G C MR D
$FG,2$_import$FG$ var G C MR D
$FG,5$Just in Time Compilation$FG$
$FG,2$G$FG$lobalScope/$FG,2$F$FG$unctionScope
| $FG,2$C$FG$odeHeap/$FG,2$D$FG$ataHeap/$FG,2$S$FG$tack/$FG,2$R$FG$egister
| | TaskHashEntry:Export$FG,2$S$FG$ysSym/$FG,2$D$FG$efine/$FG,2$F$FG$unction/$FG,2$C$FG$lass
| | | UsageScope: $FG,2$M$FG$odule/$FG,2$A$FG$smLocal/Asm$FG,2$B$FG$lk/$FG,2$T$FG$askAndChildren/$FG,2$F$FG$unction
| | | |UsageScope: $FG,2$G$FG$lbl/Asm$FG,2$L$FG$ocal/$FG,2$R$FG$emainder/$FG,2$g$FG$lblThisBlkAndRemainder
| | | || $FG,2$S$FG$taticVarInit/$FG,2$D$FG$ynamicVarInitAllowed/$FG,2$N$FG$oInitAllowed
| | | || | Are dups allowed within the namespace? A dup overshadows the original.
| | | || | $FG,2$D$FG$upsAllowed/$FG,2$N$FG$oDups/NoDupsBut$FG,2$P$FG$ad/$FG,2$W$FG$arningUnlessClosedOut
asm export $FG,2$label::$FG$ G C S Tg N
asm $FG,2$label:$FG$ G C BG N
asm local $FG,2$@@label:$FG$ G C AL N
asm $FG,2$IMPORT label;$FG$ G C TR N
asm export $FG,2$label::$FG$ F C BG N
asm $FG,2$label:$FG$ F C BG N
asm local $FG,2$@@label:$FG$ F C AL N
asm $FG,2$IMPORT label;$FG$ F C BR N
C goto $FG,2$label:$FG$ F C FG N
$FG,2$#define$FG$ x D TR D
function G C F TR D
var F R FR N
var F S FR N
$FG,2$static$FG$ var F C FR D N
var G C G TR D D
var G D G TR S D
$FG,2$class$FG$ G C TR D
class member G TR P
$FG,2$extern class$FG$ G C TR D
$FG,2$extern$FG$ function G C F TR W
$FG,2$extern$FG$ var G C G TR D
$FG,2$extern$FG$ var G D G TR D
$FG,2$_extern$FG$ function G C F TR D
$FG,2$_extern$FG$ var G C G TR D
$WW,1$
* Goto labels must not have the same name as global scope objects. GoTo's are rare and I don't want to slow the compiler and add code to fix this. You will get errors if a collision happens, so it's not very dangerous, but the error message is baffling.
* The member names $FG,2$pad$FG$ and $FG,2$reserved$FG$ are special because multiple instances with the same name are allowed in a class.
* Use $FG,2$reg$FG$ or $FG,2$noreg$FG$ in front of local var names to override automatic reg var allocation. You can, optionally, specify a reg after the $FG,2$reg$FG$ keyword.
* Local non-reg function vars can be accessed in asm blks with $FG,2$&i[RBP]$FG$ for example.
* Glbl vars and functions can be accessed in asm with and $FG,2$&$FG$ as in
$FG,2$MOV RAX,I64 [&glbl_var]
CALL I32 &Fun
CALL I32 &SYS_SYM$FG$
* In $FG,2$JIT$FG$ asm code, &SYS_SYM and &Fun don't need $FG,2$IMPORT$FG$.
* All offspring tasks of a task inherit syms.
* The $FG,2$sizeof()$FG$ and HolyC structure members can be used in asm blks.
* Using $FG,2$&i$FG$ in $LK,"HolyC",A="FI:::/Doc/HolyC.TXT"$ or $FG,2$i.u8[2]$FG$ on a local var, $FG,2$i$FG$, will force it to $FG,2$noreg$FG$.
* Using $FG,2$try$FG$/$FG,2$catch$FG$ in a function will force all local vars to $FG,2$noreg$FG$.
* An unused gap on the stk is left for $FG,2$reg$FG$ vars.
* Note: $FG,2$static$FG$ function vars do not go on the data heap, no matter the setting of the $LK,"OPTf_GLBLS_ON_DATA_HEAP",A="MN:OPTf_GLBLS_ON_DATA_HEAP"$$FG$. They may in the future.
* $LK,"OPTf_EXTERNS_TO_IMPORTS",A="MN:OPTf_EXTERNS_TO_IMPORTS"$ will treat $FG,2$_extern$FG$ as $FG,2$_import$FG$ and $FG,2$extern$FG$ as $FG,2$import$FG$. This allows a header to be used either as a $FG,2$JIT compiled$FG$ or $FG,2$AOT compiled$FG$ header.
+4 -4
View File
@@ -1,6 +1,6 @@
$WW,1$$FG,5$$TX+CX,"Memory Overview"$$FG$
Paging is practically not used. 64-bit mode requires paging to be active, however, so it is identity-mapped, virtual identical to physical. All tasks on all cores use the same page table map, just as though all addresses are physical addresses. 2 Meg page table entries are used, except the first 2 Meg, which uses 4K page tables entries. Nothing swaps to disk, either.
Paging is practically not used. 64-bit mode requires paging, however, so it is identity-mapped, virtual identical to physical. All tasks on all cores use the same page table map, just as though all addresses are physical addresses. 2 Meg page table entries are used, except the first 2 Meg, which uses 4K page tables entries. Nothing swaps to disk, either.
In TempleOS, the lowest 2 Gig of memory is called the $FG,2$code heap$FG$. TempleOS's compiler always uses 32-bit signed relative JMP & CALL instructions because 64-bit CALLs take two instructions. With signed +/- 32-bit values, code can only call a function within 2 Gig distance. Therefore, TempleOS keeps all code in the lowest 2 Gig memory addresses including what would normally be called "the kernel". Two Gig is plenty for code, don't worry.
@@ -10,14 +10,14 @@ Memory alloced by a task will be freed when the task is killed.
Eventually, memory will become fragmented, requiring a reboot.
See $LK,"MemRep",A="MN:MemRep"$().
See $LK,"MemRep",A="MN:MemRep"$() and $LK,"::/Demo/MemDemo.CPP"$.
$FG,5$$TX+CX,"Single System-wide Mem Map"$
$FG,2$ 0x0000000000- 0x00$TX,"00006FFF",D="DD_PROTECTED_LOW"$$FG$
$ID,2$Pages marked not present so NULL ptr dereference causes a fault.
$ID,-2$
$FG,2$ 0x00$TX,"00007C00",D="DD_KERNEL"$- 0x00$TX,"00034EAF",D="DD_KERNEL_END"$$FG$
$FG,2$ 0x00$TX,"00007C00",D="DD_KERNEL"$- 0x00$TX,"00034E7F",D="DD_KERNEL_END"$$FG$
$ID,2$Kernel module, placed here by the boot-loader, $LK,"BOOT_RAM_BASE",A="MN:BOOT_RAM_BASE"$.
$ID,-2$
$FG,2$ 0x00$TX,"00096600",D="DD_BOOT_HIGH_LOC_DVD"$- 0x00$TX,"00096FFF",D="DD_BOOT_HIGH_LOC_DVD_END"$$FG$
@@ -35,7 +35,7 @@ $ID,-2$
$FG,2$ 0x00$TX,"00100000",D="DD_SYS_FIXED_AREA_BASE"$- 0x00$TX,"001845FF",D="DD_SYS_FIXED_AREA_END"$$FG$
$ID,2$$LK,"CSysFixedArea",A="MN:CSysFixedArea"$ for page tables and misc. $TX,"128 Gig",D="DD_MEM_MAPPED_SPACE_GIG"$ of address space mapped.
$ID,-2$
$FG,2$ 0x00$TX,"00184600",D="DD_SYS_HEAP_BASE"$- 0x00$TX,"3FFDFEFF",D="DD_SYS_HEAP_LIMIT"$$FG$
$FG,2$ 0x00$TX,"00184600",D="DD_SYS_HEAP_BASE"$- 0x00$TX,"7FFFFFFF",D="DD_SYS_HEAP_LIMIT"$$FG$
$ID,2$Code Heap mem.
$ID,-2$
$FG,2$ - 0x007FFFFFFF$FG$
+6 -4
View File
@@ -1,12 +1,14 @@
$WW,1$TempleOS does master-slave multicore instead of SMP. $GREEN$Core#0$FG$ is the master. The master core assigns computational jobs to other cores. It is symmetrical, however, in the sense that you can freely do file access and heap allocations because there are locks. See $LK,"::/Demo/MultiCore/LoadTest.CPP"$. TempleOS does not move tasks between cores.
$WW,1$TempleOS does master-slave multicore instead of SMP. $FG,2$Core0$FG$ is the master. The master core's applications explicitly assign computational jobs to other cores and the TempleOS scheduler does not move tasks between cores.
Only tasks on core#0 can have windows, but other cores can help render them.
There are multicore safe locks for file access and heap allocations, however, so TempleOS is symmetrical in some sense. See $LK,"::/Demo/MultiCore/LoadTest.CPP"$.
Each core has a $GREEN$seth task$FG$ which is the father of all tasks on that core. Adam is the seth task on core 0.
Only tasks on $FG,2$core0$FG$ can have windows, but other cores can help render them.
Each core has an executive $FG,2$seth task$FG$ which is the father of all tasks on that core. Adam is the seth task on core 0.
You give a job to a seth task with $LK,"JobQue",A="MN:JobQue"$() and get the result with $LK,"JobResultGet",A="MN:JobResultGet"$(). You spawn a task on another core with $LK,"Spawn",A="MN:Spawn"$().
Note: You must use the $GREEN$LOCK$FG$ asm prefix when changing shared structures in a multicore environment. The $LK,"LBts",A="MN:LBts"$(), $LK,"LBtr",A="MN:LBtr"$() and $LK,"LBtc",A="MN:LBtc"$() instructions have $GREEN$LOCK$FG$ prefixes. The compiler has a $GREEN$lock{}$FG$ feature but it doesn't work well. See $LK,"::/Demo/MultiCore/Lock.CPP"$.
Note: You must use the $FG,2$LOCK$FG$ asm prefix when changing shared structures in a multicore environment. The $LK,"LBts",A="MN:LBts"$(), $LK,"LBtr",A="MN:LBtr"$() and $LK,"LBtc",A="MN:LBtc"$() instructions have $FG,2$LOCK$FG$ prefixes. The compiler has a $FG,2$lock{}$FG$ feature but it doesn't work well. See $LK,"::/Demo/MultiCore/Lock.CPP"$.
See $LK,"::/Demo/Graphics/Transform.CPP"$.
See $LK,"::/Kernel/MultiProc.CPP"$.
+17
View File
@@ -0,0 +1,17 @@
$WW,1$$FG,5$$TX+CX,"Compiler Options"$$FG$
Use $LK,"Option",A="MN:Option"$(). You might need to do $FG,2$#exe {Option();}$FG$.
$LK,"OPTf_GLBLS_ON_DATA_HEAP",A="MN:OPTf_GLBLS_ON_DATA_HEAP"$ without this option, global vars are placed in the code heap which is limited to 2 Gig. In $FG,2$AOT$FG$ modules, global vars take-up room in the $FG,2$.BIN$FG$ file, so you might want to use this option, instead. You might wish to turn it on and off around specific vars. A disadvantage of data heap global vars in $FG,2$AOT$FG$ modules is they can't be initialized.
$LK,"OPTf_EXTERNS_TO_IMPORTS",A="MN:OPTf_EXTERNS_TO_IMPORTS"$ and $LK,"OPTf_KEEP_PRIVATE",A="MN:OPTf_KEEP_PRIVATE"$ are strange options, you'll never need. They're to allow the same header file for $FG,2$Kernel$FG$ to act as $FG,2$extern$FG$s when compiling itself and $FG,2$import$FG$s when compiled by $FG,2$AOT$FG$ modules.
$LK,"OPTf_WARN_UNUSED_VAR",A="MN:OPTf_WARN_UNUSED_VAR"$ warning if unused var. It is applied to functions.
$LK,"OPTf_WARN_PAREN",A="MN:OPTf_WARN_PAREN"$ warning if parenthesis are not needed.
$LK,"OPTf_WARN_DUP_TYPES",A="MN:OPTf_WARN_DUP_TYPES"$ warning if dup local var type statements.
$LK,"OPTf_NO_REG_VAR",A="MN:OPTf_NO_REG_VAR"$ forces all function local vars to the stk not regs. Applied to functions.
$LK,"OPTf_NO_BUILTIN_CONST",A="MN:OPTf_NO_BUILTIN_CONST"$ Disable 10-byte float consts for ã, log2_10, log10_2, loge_2. Applied to functions.
+19
View File
@@ -0,0 +1,19 @@
$WW,1$$FG,5$$TX+CX,"PreProcessor"$$FG$
There is no separate preprocessor pass. The parser front-end calls $LK,"Lex",A="MN:Lex"$() which has the preprocessor built-in. The compiler looks ahead a token, most of the time, so you might throw an extra semicolon after a directive if it's not taking affect right away.
Put an extra semicolon $FG,2$#exe {Cd("DirName");;}$FG$ in case a $FG,2$#include$FG$ follows.
$FG,2$#include ""$FG$ There is no angle bracket <> form of this directive.
$FG,2$#exe {}$FG$ Will execute code at compile-time and can be used to insert code into the stream being compiled using $LK,"StreamPrint",A="MN:StreamPrint"$().
$FG,2$#define$FG$ Define string const
$FG,2$#assert$FG$ Print a warning during compilation if an expression is not true.
$FG,2$#if$FG$ Include code if an expresion is true.
$FG,2$#else
#endif
#ifdef,#ifndef $FG$Include code if a sym is defined.
$FG,2$#ifaot,#ifjit $FG$Include code if in $FG,2$AOT$FG$ compiler mode.
$FG,2$defined()$FG$ Is a function that can be used in expressions.
$FG,2$#help_index$FG$, $FG,2$#help_file$FG$ See $LK,"Help System",A="FI:::/Doc/HelpSystem.TXT"$.
See $LK,"PreProcessor",A="FF:::/Compiler/Lex.CPP,KW_DEFINE"$.
+1 -1
View File
@@ -4,7 +4,7 @@ $WW,1$* You run a risk of problems if you do file operations on the same files s
* When using $FG,2$FAT32$FG$, TempleOS does not generate unique short-entry names, the ones with the $FG,2$~$FG$s. Not all $FG,2$FAT32$FG$ filenames are valid TempleOS names and it will complain. Do not access $FG,2$FAT32$FG$ drives not dedicated to TempleOS. Disable them with $LK,"DrvEnable",A="MN:DrvEnable"$(OFF), or they will generate error messages. $FG,2$FAT32$FG$ involves a long and short name for each file.
* The stk does not grow because virtual mem is not used. I recommend allocating large local vars from the heap. You can change $LK,"DFT_STK",A="MN:DFT_STK"$ and recompile $FG,2$Kernel$FG$ or request more when doing a $LK,"Spawn",A="MN:Spawn"$().
* The stk does not grow because virtual mem is not used. I recommend allocating large local vars from the heap. You can change $LK,"MEM_DFT_STK",A="MN:MEM_DFT_STK"$ and recompile $FG,2$Kernel$FG$ or request more when doing a $LK,"Spawn",A="MN:Spawn"$().
* The syntax highlighting occassionally glitches. The compiler doesn't.
+120
View File
@@ -0,0 +1,120 @@
$PURPLE$$TX+CX,"Scoping and Linkage"$$FG$
$WW,1$
$LK,"JIT Compile Mode",A="FF:::/Doc/Glossary.TXT,JIT Compile Mode"$ makes use of the current task's hash sym table and its parent tasks' tables. It fetches syms from parent tasks' tables if not found locally in the current task's table and it places new syms in the current task's table. Conceptually, syms are at the scope of environment vars in other operating systems.
When a sym is placed into a table, older syms with identical names will be overshadowed if they exist. Duplicates are not allowed in many cases, especially in asm blks. Dupicates are allowed, by design in other cases, so that you can repeatedly $GREEN$#include$FG$ the same file from the cmd line while developing it. Or, so you can repeatedly declare a function with a standard name, like $GREEN$DrawIt()$FG$. This case might occur when the $GREEN$adam task$FG$ is starting-up loading-in many little utilities.
$GREEN$extern$FG$ binds a new $LK,"HTT_FUN",A="MN:HTT_FUN"$ or $LK,"HTT_GLBL_VAR",A="MN:HTT_GLBL_VAR"$ sym to an existing sym of the same name if it exists in the sym table (just in just-in-time code). It also can be used to generate a fwd reference.
$GREEN$import$FG$ binds a new $LK,"HTT_FUN",A="MN:HTT_FUN"$ or $LK,"HTT_GLBL_VAR",A="MN:HTT_GLBL_VAR"$ sym to a sym of the same name imported from the task's sym table at $LK,"Load",A="MN:Load"$() time. If no sym exists to bind to at $LK,"Load",A="MN:Load"$() time, the code using this sym will be left incomplete until the sym is defined.
$WW,1$
$GREEN$_extern$FG$ binds a new $LK,"HTT_FUN",A="MN:HTT_FUN"$ or $LK,"HTT_GLBL_VAR",A="MN:HTT_GLBL_VAR"$ sym to an existing sym, of a $BK,1$different$BK,0$ name. It must exists in the sym table. Basically, this binds C to asm.
$GREEN$_import$FG$ binds a new $LK,"HTT_FUN",A="MN:HTT_FUN"$ or $LK,"HTT_GLBL_VAR",A="MN:HTT_GLBL_VAR"$ sym to a sym, of a $BK,1$different$BK,0$ name imported from the task's sym table at $LK,"Load",A="MN:Load"$() time. If no sym exists to bind to at $LK,"Load",A="MN:Load"$() time, the code using this sym will be left incomplete until the sym is defined. Basically, this binds C to asm from elsewhere.
$WW,0$$PURPLE$Ahead of Time Compilation$FG$
$GREEN$G$FG$lobalScope/$GREEN$F$FG$unctionScope
| $GREEN$C$FG$odeHeap/$GREEN$D$FG$ataHeap/$GREEN$S$FG$tack/$GREEN$R$FG$egister
| | TaskHashEntry:Export$GREEN$S$FG$ysSym/$GREEN$D$FG$efine/$GREEN$F$FG$unction/$GREEN$C$FG$lass
| | | UsageScope: $GREEN$M$FG$odule/$GREEN$A$FG$smLocal/Asm$GREEN$B$FG$lk/$GREEN$T$FG$askAndChildren/$GREEN$F$FG$unction
| | | |UsageScope: $GREEN$G$FG$lbl/Asm$GREEN$L$FG$ocal/$GREEN$R$FG$emainder/$GREEN$g$FG$lblThisBlkAndRemainder
| | | || $GREEN$S$FG$taticVarInit/$GREEN$D$FG$ynamicVarInitAllowed/$GREEN$N$FG$oInitAllowed
| | | || | Are dups allowed within the namespace? A dup overshadows the original.
| | | || | $GREEN$D$FG$upsAllowed/$GREEN$N$FG$oDups/NoDupsBut$GREEN$P$FG$ad/$GREEN$W$FG$arningUnlessClosedOut
asm export $GREEN$label::$FG$ G C S MG N
asm $GREEN$label:$FG$ G C MG N
asm local $GREEN$@@label:$FG$ G C AL N
asm $GREEN$IMPORT label;$FG$ G C MR N
asm export $GREEN$label::$FG$ F C S BG N
asm $GREEN$label:$FG$ F C BG N
asm local $GREEN$@@label:$FG$ F C AL N
asm $GREEN$IMPORT label;$FG$ F C BR N
C goto $GREEN$label:$FG$ F C FG N
$GREEN$#define$FG$ x MR D
function G C S MR D
var F R FR N
var F S FR N
$GREEN$static$FG$ var F C FR D N
var G C S MR D D
var G D MR N D
$GREEN$class$FG$ G MR D
class member G MR P
$GREEN$extern class$FG$ G MR D
$GREEN$extern$FG$ function G C MR W
$GREEN$import$FG$ function G C MR D
$GREEN$import$FG$ var G C MR D
$GREEN$_extern$FG$ function G C MR D
$GREEN$_extern$FG$ var G C MR D
$GREEN$_import$FG$ function G C MR D
$GREEN$_import$FG$ var G C MR D
$PURPLE$Just in Time Compilation$FG$
$GREEN$G$FG$lobalScope/$GREEN$F$FG$unctionScope
| $GREEN$C$FG$odeHeap/$GREEN$D$FG$ataHeap/$GREEN$S$FG$tack/$GREEN$R$FG$egister
| | TaskHashEntry:Export$GREEN$S$FG$ysSym/$GREEN$D$FG$efine/$GREEN$F$FG$unction/$GREEN$C$FG$lass
| | | UsageScope: $GREEN$M$FG$odule/$GREEN$A$FG$smLocal/Asm$GREEN$B$FG$lk/$GREEN$T$FG$askAndChildren/$GREEN$F$FG$unction
| | | |UsageScope: $GREEN$G$FG$lbl/Asm$GREEN$L$FG$ocal/$GREEN$R$FG$emainder/$GREEN$g$FG$lblThisBlkAndRemainder
| | | || $GREEN$S$FG$taticVarInit/$GREEN$D$FG$ynamicVarInitAllowed/$GREEN$N$FG$oInitAllowed
| | | || | Are dups allowed within the namespace? A dup overshadows the original.
| | | || | $GREEN$D$FG$upsAllowed/$GREEN$N$FG$oDups/NoDupsBut$GREEN$P$FG$ad/$GREEN$W$FG$arningUnlessClosedOut
asm export $GREEN$label::$FG$ G C S Tg N
asm $GREEN$label:$FG$ G C BG N
asm local $GREEN$@@label:$FG$ G C AL N
asm $GREEN$IMPORT label;$FG$ G C TR N
asm export $GREEN$label::$FG$ F C BG N
asm $GREEN$label:$FG$ F C BG N
asm local $GREEN$@@label:$FG$ F C AL N
asm $GREEN$IMPORT label;$FG$ F C BR N
C goto $GREEN$label:$FG$ F C FG N
$GREEN$#define$FG$ x D TR D
function G C F TR D
var F R FR N
var F S FR N
$GREEN$static$FG$ var F C FR D N
var G C G TR D D
var G D G TR S D
$GREEN$class$FG$ G C TR D
class member G TR P
$GREEN$extern class$FG$ G C TR D
$GREEN$extern$FG$ function G C F TR W
$GREEN$extern$FG$ var G C G TR D
$GREEN$extern$FG$ var G D G TR D
$GREEN$_extern$FG$ function G C F TR D
$GREEN$_extern$FG$ var G C G TR D
$WW,1$
* Goto labels must not have the same name as global scope objects. GoTo's are rare and I don't want to slow the compiler and add code to fix this. You will get errors if a collision happens, so it's not very dangerous, but the error message is baffling.
* The member names $GREEN$pad$FG$ and $GREEN$reserved$FG$ are special because multiple instances with the same name are allowed in a class.
* Use $GREEN$reg$FG$ or $GREEN$noreg$FG$ in front of local var names to override automatic reg var allocation. You can, optionally, specify a reg after the $GREEN$reg$FG$ keyword.
* Local non-reg function vars can be accessed in asm blks with $GREEN$&i[RBP]$FG$ for example.
* Glbl vars and functions can be accessed in asm with and $GREEN$&$FG$ as in
$GREEN$MOV RAX,I64 [&glbl_var]
CALL I32 &Fun
CALL I32 &SYS_SYM$FG$
* In $GREEN$JIT$FG$ asm code, &SYS_SYM and &Fun don't need $GREEN$IMPORT$FG$.
* All offspring tasks of a task inherit syms.
* The $GREEN$sizeof()$FG$ and HolyC structure members can be used in asm blks.
* Using $GREEN$&i$FG$ in $LK,"HolyC",A="FI:::/Doc/HolyC.TXT"$ or $GREEN$i.u8[2]$FG$ on a local var, $GREEN$i$FG$, will force it to $GREEN$noreg$FG$.
* Using $GREEN$try$FG$/$GREEN$catch$FG$ in a function will force all local vars to $GREEN$noreg$FG$.
* An unused gap on the stk is left for $GREEN$reg$FG$ vars.
* Note: $GREEN$static$FG$ function vars do not go on the data heap, no matter the setting of the $LK,"OPTf_GLBLS_ON_DATA_HEAP",A="MN:OPTf_GLBLS_ON_DATA_HEAP"$$FG$. They may in the future.
* $LK,"OPTf_EXTERNS_TO_IMPORTS",A="MN:OPTf_EXTERNS_TO_IMPORTS"$ will treat $GREEN$_extern$FG$ as $GREEN$_import$FG$ and $GREEN$extern$FG$ as $GREEN$import$FG$. This allows a header to be used either as a $GREEN$JIT compiled$FG$ or $GREEN$AOT compiled$FG$ header.
+1 -1
View File
@@ -52,7 +52,7 @@ A three button mouse is like a leg you cannot put weight on. TempleOS just does
* The $LK,"Scheduler",A="FI:::/Kernel/Sched.CPP"$ is for home systems. It is not preemptiove. Disk requests are not broken-up, so sharing is bad. It's wonderfully simple.
* $LK,"MultiCore",A="FI:::/Doc/MultiCore.TXT"$ is done $FG,2$master/slave$FG$, instead of $FG,2$SMP$FG$. Core zero explicitly assigns jobs. Locks are present allowing multicore file, heap, and hardware access, though.
* $LK,"MultiCore",A="FI:::/Doc/MultiCore.TXT"$ is done $FG,2$master/slave$FG$, instead of $FG,2$SMP$FG$. $FG,2$Core0$FG$ applications explicitly assigns jobs. Locks are present allowing multicore file, heap, and hardware access, though.
* $LK,"Music",A="MN:Play"$ is done with an elegant one-voice notation.
BIN
View File
Binary file not shown.
+1 -1
View File
@@ -43,7 +43,7 @@ $FG,2$Merge(\"C:/*\",\"D:/*\",\"+r+d\");$FG$ to check my changes.
* Many data structures have a $FG,2$user_data$FG$ member. Those are available for you to store a data item, for convenience. $LK,"CTask",A="MN:CTask"$, $LK,"CDocEntry",A="MN:CDocEntry"$ and $LK,"CDirEntry",A="MN:CDirEntry"$ have them. You shouldn't encounter conflicts with TempleOS using them.
* If, for some strange reason, you wanted to reduce mem usage, make a smaller disk cache when you recompile the kernel; disabling $FG,2$AutoComplete$FG$; Specify smaller stk sizes when doing $LK,"Spawn",A="MN:Spawn"$(), chang $LK,"DFT_STK",A="MN:DFT_STK"$, and using $LK,"DocMax",A="MN:DocMax"$() to reduce the cmd line buffer size.
* If, for some strange reason, you wanted to reduce mem usage, make a smaller disk cache when you recompile the kernel; disabling $FG,2$AutoComplete$FG$; Specify smaller stk sizes when doing $LK,"Spawn",A="MN:Spawn"$(), chang $LK,"MEM_DFT_STK",A="MN:MEM_DFT_STK"$, and using $LK,"DocMax",A="MN:DocMax"$() to reduce the cmd line buffer size.
* Filenames ending in "$FG,2$.Z$FG$" will be automatically compressed and uncompressed when read or written. The compression method is not supported by other operating systems. You can store files uncompressed by $LK,"Move",A="MN:Move"$()ing them to a filename not ending in "$FG,2$.Z$FG$". See $LK,"::/Doc/TOSZ.TXT"$ if you want to uncompress while in $FG,2$Linux$FG$.
+3 -3
View File
@@ -1,13 +1,13 @@
$WW,1$$FG,5$$TX+CX,"Welcome to TempleOS"$$FG$
TempleOS is a x86_64, multi-cored, multi-tasking, ring-0-only, single-address_mapped (identity-mapped), operating system for recreational programming. Paging is almost not used.
TempleOS is a x86_64, multi-cored, non-preemptive multi-tasking, ring-0-only, single-address_mapped (identity-mapped), operating system for recreational programming. Paging is almost not used.
The people whom can most benefit are:
$ID,2$* Professionals doing hobby projects
* Teenagers doing projects
* Non-professional, older-persons projects
$ID,-2$
Simplicity is a goal to $LK,"keep the line count down",A="FI:::/Doc/Strategy.TXT"$, so it's easy to tinker with. As it turns-out, simplicity makes it faster in some ways, too. It never switches privilege levels, never changes address maps, tends to load whole contiguous files and other, similar things which boost speed. It's only $TX,"118,751",D="DD_TEMPLEOS_LOC"$ lines of code including the kernel, the 64-bit compiler, the graphics library and all the tools. More importantly, it's designed to keep the user's line count down -- you can do a $LK,"Hello World",A="FI:::/Doc/HelloWorld.TXT"$ application in one line of code and can put graphics on the screen with a three line program!
Simplicity is a goal to $LK,"keep the line count down",A="FI:::/Doc/Strategy.TXT"$, so it's easy to tinker with. As it turns-out, simplicity makes it faster in some ways, too. It never switches privilege levels, never changes address maps, tends to load whole contiguous files and other, similar things which boost speed. It's only $TX,"80,940",D="DD_TEMPLEOS_LOC_OFFICIAL"$ lines of code including the kernel, the 64-bit compiler, the graphics library and all the tools. More importantly, it's designed to keep the user's line count down -- you can do a $LK,"Hello World",A="FI:::/Doc/HelloWorld.TXT"$ application in one line of code and can put graphics on the screen with a three line program!
It's a kayak, not a Titanic -- it will crash if you do something wrong. You quickly reboot, however. DOS and the 8-bit home computers of the 80's worked fine without memory protection and most computers in the world -- the embedded ones -- operate without protection. The resulting simplicity of no protections is why TempleOS has value. In facts, that's the point of TempleOS. See the $LK,"TempleOS Charter",A="FI:::/Doc/Charter.TXT"$.
@@ -15,7 +15,7 @@ Conventional thinking is "failure is not an option" for general purpose operatin
Two things to know about TempleOS are that $UL,1$tasks$UL,0$ have $LK,"MAlloc",A="MN:MAlloc"$/$LK,"Free",A="MN:Free"$ heap memory, not applications, and tasks have compiler symbol tables that persist at a scope like environment variables in other operating systems, and the symbols can include functions.
In other operating systems, I hated learning one language for command line scripts and another for programming. With $FG,2$TempleOS$FG$, the command line feeds right into the $LK,"HolyC",A="FI:::/Doc/HolyC.TXT"$ compiler, line by line, and it places code into memory it $LK,"MAlloc",A="MN:MAlloc"$()s. The compiler is paused at the command line, waiting for input. Naturally, you $FG,2$#include$FG$ a program to load it into memory and, usually, start it. See $LK,"::/Doc/HelloWorld.TXT"$.
In other operating systems, I hated learning one language for command line scripts and another for programming. With $FG,2$TempleOS$FG$, the command line feeds right into the $LK,"HolyC",A="FI:::/Doc/HolyC.TXT"$ compiler, line by line, and it places code into memory it $LK,"MAlloc",A="MN:MAlloc"$()s. The compiler is paused at the command line, waiting for input. Naturally, you $FG,2$#include$FG$ a program to load it into memory and, usually, start it.
During the boot process, many files get $LK,"compiled",A="FI:::/StartOS.CPP"$ before you have access to the command line. (Don't worry, booting takes only a couple of seconds.) All the header declarations for the operating system are compiled and are available for use in your programs without needing to $FG,2$#include $FG$them. Everything is truly compiled to native $FG,2$$TX,"x86_64",HTML="http://en.wikipedia.org/wiki/Amd64#AMD64"$$FG$ machine code, nothing is $FG,2$interpreted$FG$ and there is no $FG,2$byte code$FG$.
+1
View File
@@ -0,0 +1 @@
$WW,1$Only tasks on $FG,2$core0$FG$ can have a window and there can be only one window per task. The window Z-buffer, top-to-bottom order is determined by the order in the task queue, with the $FG,2$WinMgr$FG$ on the bottom. A task can have child task popup windows.