The real-mode version of smx86 is intended for users who are using 8086, 186, or equivalent processors or who do not have large applications and do not need the protection mechanisms of 386-class processors. smx86 is also used for running with DOS. (See the section on DOS Support in the smx86 brochure.)

Real mode is often attractive because it is simple and well understood. Also, debugging can be easily performed in a DOS environment on the host machine. Often, projects are upgrading from 186 to 386-class processors simply to gain performance, not to gain increased memory. In such cases it makes sense to stay with real mode.

Real Mode Summary

The 16spm version of smx86 is intended for users who have exceeded the 1 megabyte limit of real-mode, or the 640KB limit of DOS, or who want the segment protection offered by the 386-class processors, but who wish to continue using familiar tools. This version provides an easy step into protected mode from real mode. There should be little change required to the application code, since it is still 16-bit C/C++ code.

Although 16-bit Windows has faded into obscurity, 16-bit segmented protected mode is not obsolete for embedded systems. It offers many worthwhile advantages over its siblings, real mode and 32fpm. (See the sidebar for a discussion of these.) The main disadvantage of 16spm is aging tools. The 16-bit Borland and Microsoft tools are becoming more difficult to find and the Soft-Scope debugger is an older-generation debugger. However, for many real-mode projects, being able to continue using familiar tools far outweighs these considerations.


16-bit Protected Mode Summary

*Contrary to common belief, 32-bit operations and > 64 KB segments arepossible in 16-bit protected mode. However, such code must be written in assembly language and smx source code is required for this.

It is unfortunate that the industry, in general, has adopted 32fpm and has eschewed segmentation. The debugging advantages of 16spm are well worth noting. Those who have worked in this environment are reluctant to give it up. This is because difficult-to-find bugs, such as pointer errors and buffer or stack overflow errors, are caught immediately and do not waste major debug time. Often, these kinds of errors cause intermittent bugs, which may plague products for years. Particularly insidious are errors that overwrite unused memory until some minor change is made that causes the memory to become used. Then, the frustration begins because the change has nothing to do with the bug, which is in some other section of code. Of course, eliminating these nasty bugs not only reduces debug time, but also improves product reliability and creates a better customer impression.

Functionally, there is no difference between the services provided by the 16spm version and those provided by the real-mode version of smx86, except for the far heap. Each block of the far heap (including far stacks) is in a separate segment that has its own selector and segment descriptor. The segment descriptor specifies the base address and size of the segment. Each block is protected from all other blocks. Any access outside a block will generate an immediate general protection fault (gpf), which causes the debugger to immediately halt on the offending instruction. This is tremendous for catching stack overflows or heap block overflows, since the processor will halt right when it happens. When not debugging, the gpf handler in pmEasy reports the error, or the user can write his own gpf handler, if desired. Either way, this feature helps to isolate tasks from each other. Performance of 16spm is somewhat slower than real mode or 32fpm, since hidden descriptor registers are loaded each time a segment register is changed.


16-bit Protected Mode Tradeoffs

Advantages vs. real-mode

1. Greatly expanded memory space (4 GB).
2. Segment protection and other processor checks (e.g. general protection fault and stack fault).

Advantages vs. 32fpm

1. Segment protection.
2. Easier upgrade path from existing real-mode code to protected mode.
   * Changes to code are minimal.
   * Can continue using the same compiler as for real-mode.
3. Smaller code and data sizes.

Disadvantages vs. 32fpm

1. 64KB limit on segments and data structures for C/C++ code. (However,assembly code can overcome this limitation.)
2. Changing segment registers reduces performance.
3. Fewer tools and 3rd party libraries available.

32-bit Flat Protected Mode (32 fpm)

The 32fpm version of smx86 provides 32-bit protected mode support, without segmentation. Assembly language portions of smx86 have been rewritten to take advantage of 32-bit instructions. C language portions are compiled with 32-bit compilers.

The services provided by this version are the same as real-mode and 16spm smx86 except for the omission of the far heap, far stacks, and other far objects. A single flat-model smx library is provided. When smxSim is also purchased, a special library is provided that is suitable for execution in a Win32 environment.

Because of the large addressing range (4 GB) of 32-bit offsets and the lack of segmentation, many users prefer flat-mode addressing. This is the only 32-bit mode is supported by the Microsoft, Borland, and Paradigm 32-bit compilers. In this mode, segment registers are loaded only once, during startup. This is a conceptually simple model, since everything is near. Programmers familiar with other 32-bit processors, such as the 68000, find this version to be a welcome entry into the x86 world.

The downside to the flat-mode addressing scheme is that the developer gives up the superior debugging support and enhanced reliability inherent in segmented protected mode. (See the discussion under 16-bit Protected Mode.)

Note that if the goal is to achieve more efficient code for 32-bit operations (such as integer arithmetic), it is not necessary to use 32-bit smx, since the 16-bit versions support use of the processor 3 compiler switch (for 386-class processors). This allows the compiler to use 32-bit registers. (See Using 32-bit Registers in 16-bit Modes in the articles section of www.smxrtos.com.) This option requires smx source code.

32-bit Flat Protected Mode Tradeoffs

Advantages vs. 16-bit smx86

1. 32-bit offsets remove the 64KB limits on segments, arrays, etc. for C/C++ code.
2. Flat memory model is more comfortable to programmers familiar with other 32-bit processors.
3. Better tool and 3rd party library support.

Disadvantages vs. 16-bit smx86

1. No segment protection.
2. Less efficient memory utilization.
3. Slower execution for processors with 16-bit data paths.

Easy Upgrade Path from Real Mode to Protected Mode with smx86

smx86 is ideal for real-mode projects that may need to move to protected mode in the future, in order to obtain more address space, or for other reasons. This is because smx86 makes the transition as easy as possible. Assuming an application is developed based upon the real-mode Protosystem, upgrading to protected mode requires little more than moving the application to the protected-mode Protosystem, which has the same structure as the real-mode Protosystem. The smx API is unchanged, except for the lack of far objects in 32fpm.

Moving to 16spm from real mode is especially easy, since the same Borland or Microsoft tools can be used to compile and link. (Paradigm C++ does not support 16spm, at this time.) However, any segment arithmetic and huge pointers must be removed from the application code. (These changes relate to the x86 architecture, not to smx.)

When moving to 32fpm, some code changes are required due to the lack of far objects and pointers, the lack of segmentation, the lack of the interrupt keyword for Borland, Microsoft, and Paradigm compilers, and the change in definition of the int type to 32 bits from 16 bits. As with 16spm, segment arithmetic and huge pointers must be removed. It is also necessary to switch to the 32-bit versions of compilers, linkers, locators, and debuggers. In addition, most 32-bit tools require a Windows operating environment and will not run in DOS.

16spm Advantages Over MMU Paging

16-bit segmented protected mode (16spm) provides protection between data areas and between code segments which is more efficient and faster than that afforded by Memory Management Unit (MMU) paging. With an MMU, the unit of protection is usually a 4KB page. With 16spm, the unit of protection is a segment of the exact size required. Thus, memory efficiency is much better for 16spm. smx allows each far stack, each block from the far heap, and each far data area to have its own segment. In addition, each code module is put into its own code segment, for medium and large memory models.

Performance is another area where 16spm offers an advantage. With an MMU, when a page is not already in the Translation Look-aside Buffer (TLB), the page tables must be accessed and the TLB updated. With 16spm, when a segment register is changed, the 8-byte segment descriptor must be loaded into hidden registers in the processor. These two operations are comparable, in time. However, a page is only 4KB whereas as segment can be up to 64KB. Thus, changing segments potentially occurs less often. Furthermore, when a task switch occurs, the TLB usually must be flushed which can cost up to 364 cycles on a 486 and up to 1196 cycles on a Pentium. For 16spm, only two segment registers normally change on a task switch (cs and ss).

Please contact me with any comments or questions about this article.

David Moore
Director of Development
Micro Digital Inc
1-800-366-2491

back to White Papers page