GeneveOS Memory Management Functions - Revision history

Mizapf: Mizapf moved page Geneve Memory Management Functions to GeneveOS Memory Management Functions

2022-04-24T17:27:14Z

Mizapf moved page Geneve Memory Management Functions to GeneveOS Memory Management Functions

← Older revision	Revision as of 17:27, 24 April 2022
(No difference)

Mizapf: Mizapf moved page MDOS Memory Management Functions to Geneve Memory Management Functions: OS renaming

2021-01-26T21:31:19Z

Mizapf moved page MDOS Memory Management Functions to Geneve Memory Management Functions: OS renaming

← Older revision	Revision as of 21:31, 26 January 2021
(No difference)

Stephen Shaw: /* Introduction and terminology */ refer missing pages link to wikipedia article. If special TI content required create page.

2014-11-15T16:09:28Z

Introduction and terminology: refer missing pages link to wikipedia article. If special TI content required create page.

← Older revision		Revision as of 16:09, 15 November 2014
Line 7:		Line 7:
	== Introduction and terminology ==		== Introduction and terminology ==

	As it was common with TI application programming, buffers were usually placed statically in the program, that is, a portion of memory (like 256 bytes) was reserved in the program code to be used for storing data. Assembly language offers the [[BSS]] and [[BES]] directives for this purpose. This is not recommended when the buffer is very big, like 12 KiB, since that space will bloat the program code that must be loaded on application start. It is impossible for even larger buffer spaces like 100 KiB. In that cases, dynamic allocation is the typical solution also known from other systems.		As it was common with TI application programming, buffers were usually placed statically in the program, that is, a portion of memory (like 256 bytes) was reserved in the program code to be used for storing data. Assembly language offers the [https://en.wikipedia.org/wiki/.bss BSS and BES] directives for this purpose. This is not recommended when the buffer is very big, like 12 KiB, since that space will bloat the program code that must be loaded on application start. It is impossible for even larger buffer spaces like 100 KiB. In that cases, dynamic allocation is the typical solution also known from other systems.

	The Geneve offers 512 KiB of slow RAM and another 32 KiB of fast RAM. Starting from MDOS 2.5, the fast RAM must be [[Geneve_9640#Memory_Expansion \| expanded]] to 64 KiB. Obviously, this memory can only be effectively used with the help of memory management functions.		The Geneve offers 512 KiB of slow RAM and another 32 KiB of fast RAM. Starting from MDOS 2.5, the fast RAM must be [[Geneve_9640#Memory_Expansion \| expanded]] to 64 KiB. Obviously, this memory can only be effectively used with the help of memory management functions.

Mizapf: /* Free pages */

2011-11-13T20:34:31Z

Free pages

← Older revision		Revision as of 20:34, 13 November 2011
Line 180:		Line 180:
	\|}		\|}

	Error code 2 is returned when the local page address (R2) is 0; page 0 cannot be freed in this way~~. Note that shared pages are not freed by this function~~.		Returns allocated pages to the pool of free pages. When the application terminates, all assigned pages are returned automatically, so this function is mainly used when the application explicitly wants to return memory during its runtime. Shared pages cannot be freed by this function.

			Error code 2 is returned when the local page address (R2) is 0; page 0 cannot be freed in this way.

	=== Map local page at execution page ===		=== Map local page at execution page ===

Mizapf: /* Map local page at excution page */

2011-11-13T20:32:45Z

Map local page at excution page

← Older revision		Revision as of 20:32, 13 November 2011
Line 182:		Line 182:
	Error code 2 is returned when the local page address (R2) is 0; page 0 cannot be freed in this way. Note that shared pages are not freed by this function.		Error code 2 is returned when the local page address (R2) is 0; page 0 cannot be freed in this way. Note that shared pages are not freed by this function.

	=== Map local page at ~~excution~~ page ===		=== Map local page at execution page ===

	'''Opcode: 3'''		'''Opcode: 3'''

Mizapf: /* User-task XOPs */

2011-11-13T17:30:21Z

User-task XOPs

← Older revision		Revision as of 17:30, 13 November 2011
Line 97:		Line 97:
	LI R2,10 // Starting at local page 10		LI R2,10 // Starting at local page 10
	CLR R3 // Slow mem is OK		CLR R3 // Slow mem is OK
	XOP @SEVEN,0 // Invoke XOP		XOP @SEVEN,0 // Invoke XOP
	...		...

Mizapf at 17:29, 13 November 2011

2011-11-13T17:29:33Z

← Older revision		Revision as of 17:29, 13 November 2011
Line 89:		Line 89:
	== User-task XOPs ==		== User-task XOPs ==

	User-task XOPs are available for use in application programs.		User-task XOPs are available for use in application programs. Here is a typical example:

			SEVEN DATA 7
			...
			GETMEM LI R0,1 // Allocate
			LI R1,5 // 5 pages (=40 KiB)
			LI R2,10 // Starting at local page 10
			CLR R3 // Slow mem is OK
			XOP @SEVEN,0 // Invoke XOP
			...

	=== Available memory pages ===		=== Available memory pages ===

Mizapf: /* Introduction and terminology */

2011-11-13T17:22:51Z

Introduction and terminology

← Older revision		Revision as of 17:22, 13 November 2011
Line 9:		Line 9:
	As it was common with TI application programming, buffers were usually placed statically in the program, that is, a portion of memory (like 256 bytes) was reserved in the program code to be used for storing data. Assembly language offers the [[BSS]] and [[BES]] directives for this purpose. This is not recommended when the buffer is very big, like 12 KiB, since that space will bloat the program code that must be loaded on application start. It is impossible for even larger buffer spaces like 100 KiB. In that cases, dynamic allocation is the typical solution also known from other systems.		As it was common with TI application programming, buffers were usually placed statically in the program, that is, a portion of memory (like 256 bytes) was reserved in the program code to be used for storing data. Assembly language offers the [[BSS]] and [[BES]] directives for this purpose. This is not recommended when the buffer is very big, like 12 KiB, since that space will bloat the program code that must be loaded on application start. It is impossible for even larger buffer spaces like 100 KiB. In that cases, dynamic allocation is the typical solution also known from other systems.

	The Geneve offers 512 KiB of slow RAM and another 32 KiB of fast RAM. Starting from MDOS 2.5, the fast RAM must be [[~~Geneve Fast RAM expansion~~ \| expanded]] to 64 KiB. Obviously, this memory can only be effectively used with the help of memory management functions.		The Geneve offers 512 KiB of slow RAM and another 32 KiB of fast RAM. Starting from MDOS 2.5, the fast RAM must be [[Geneve_9640#Memory_Expansion \| expanded]] to 64 KiB. Obviously, this memory can only be effectively used with the help of memory management functions.

	=== Logical address space and execution pages ===		=== Logical address space and execution pages ===

Mizapf: /* Return size of shared page group */

2011-11-13T17:20:03Z

Return size of shared page group

← Older revision		Revision as of 17:20, 13 November 2011
Line 303:		Line 303:
	\|-		\|-
	\| R0		\| R0
	\| Opcode (0008) \|\| Error code		\| Opcode (0008) \|\| Error code (0, 6)
	\|-		\|-
	\| R1		\| R1

Mizapf: /* Privileged XOPs (only available for operating system) */

2011-11-13T17:19:03Z

Privileged XOPs (only available for operating system)

← Older revision		Revision as of 17:19, 13 November 2011
Line 329:		Line 329:
	\|-		\|-
	\| R1		\| R1
	\| First node		\| First node \|\|
	\|}		\|}