Solving The 386EX Software Dilemma

As long-time specialists in emulation and programming tools for Intel x86 family processors, we have become very
concerned at the scale of the problems that new 386EX users are experiencing. We have seen too many projects come to a
complete halt due to the use of inappropriate tools. In the process of developing 32 bit protected mode programs for our T32
emulator we have evaluated a number of poular compilers, linkers, monitors etc.. The results of this exercise are as follows,
culminating in our recommendation of the Phar Lap TNT Embedded Toolsuite for 32-bit embedded software development.
Practicalities Of 386EX Software
Historically the x86 architecture has evolved along two separate paths; starting life in 1976 as "general purpose" micro
designed to compete with the 68k and Z8000, the 8086/88 was soon adopted by IBM as the core of its new Personal
Computer.
Since then the x86 architecture has had two distinct and separate lives, one as a PC-engine and the other as an embedded
processor.
In the desktop world, the pace of change has been astronomic, resulting in the 64-bit Pentium becoming the industry-
standard CPU by 1995.
In the embedded world, the pace has been somewhat more leisurely, with the 16-bit 186 family being dominant. Chip
manufacturers Intel, AMD and NEC continue to develop and enhance this faithful workhorse with new variants, higher clock
speeds and new features.
The arrival of the 386ex looks likely to change this situation, it being the first real attempt at a 32-bit embedded x86 CPU,
with features like SMM power-down management, fully static core and a set of useful peripherals.
Because of its mixed parentage, the 386ex represents a bridge product between the embedded and desktop worlds and will
enable the transfer of a vast range of DOS-based and other applications into embedded sockets, particularly into the areas
of data collection, point-of-sale terminals, hand-held computing etc. A wealth of familiar software tools are available to
facilitate this process, including embedded BIOS, DOS, Compilers, debuggers etc.
The major limitation with this route is that it restricts the application to a 16-bit Real Mode, single task environment running in
a maximum of 640K of memory. This harks back to 1985 PC technology, with performance to match! The memory limitation
of itself can provide a significant barrier to application development where a memory-hungry C/C++ compiler is employed,
and this can be a source of much frustration.
There is an analogous situation in the desktop world where 16-bit operating systems like DOS and Windows 3 have held
sway until the arrival of the WIN32 extension to Windows 3, and more recently the release of Windows 95 and NT, which
offer improved support for 32-bit PC applications.
It seems that software developers have known about the benefits of 32-bit processors for a long time, but their use presents
a daunting array of technical challenges which few have been willing to accept. It is said that IBM's failure to grasp the
implications of protected mode was the main reason for OS/2's late and timid entry into the desktop market.
This is a terrible waste when the 386/486 family offers true 32-bitness, up to 4TB address range and a sophisticated virtual
memory management and protection scheme which is ideally suited to the demands of modern high-integrity software.
But how to take advantage of this programmer's Nirvana?
The three main routes are:
1) Stay with DOS, but find a way round the 640 k limit, e.g. via Extended or Expanded memory, DPMI, VCPI etc. This
method is from the software point of view the simplest as effectively the system is really just a PC. It can be the most
expensive as both the BIOS and MS-DOS must be licenced. Thus for high volume products, considerable amounts of money
can be involved in just getting to the point where application coding can begin and once in production, the royalties for
incorporated software can become a major issue. MS-DOS is not a multi-tasking operating system and has almost zero real
time capabilities and its poor performance has been widely criticised since it appeared in 1981.
This approach is usually for real mode only but the 1MB limit can be broken by using a DOS extender like EMM386.SYS or
PharLap's more sophisticated DOS|EXTENDER. However, such techniques have virtually disappeared on PCs and always
were regarded as suspect. It seems odd that companies should want to design "21st century" products using now-
abandoned 1980's PC software techniques.
Due to the sheer number of layers between the application software and the hardware plus the non-existent real time
performance of MS-DOS, the BIOS/MS-DOS route is best reserved for non-safety critical applications with zero real time
content, for example retail systems, or where third-parties want to create their own applications using a standard PC
compiler.
The software licencing cost of creating a PC-like platform should not be underestimated. On low volume products, it would
be quite easy to add $40 to the basic system cost for small programs, with a DOS extender contributing an extra $20. On
very high volume products, the annual payout to the licencers could run into hundreds of thousands of dollars. This "PC
premium" makes the 386EX a very expensive processor indeed and in plain performance terms, 25MHz 386 PCs are now
very old hat! Despite all the technical drawbacks of the BIOS/MS-DOS format, many technically-undemanding applications
find this approach satisfactory.
2) Change to a true embedded toolsuite which knows nothing about DOS and 640K limits.
Since Intel dropped its own embedded tools, this area has become the domain of one or two specialist companies, whose
products, while being of high quality, tend to be rather expensive compared to their "mass-market" equivalents.
There is also a significant learning-curve involved in their implementation as they represent a major departure from the PC
compiler route.

3) Provide 32-bit Run-Time Support on the target system.

This route has the major advantage that it allows the use of familiar PC-compilers to produce 32-bit protected mode
applications, whilst also providing additional services like multitasking support and on-target debug facilities. The downsides
are largely commercial, with some vendors extracting large royalties for incorporations and support.
The two most familiar embedded run-time systems are Intel's RMX386 and Phar Lap's Embedded Toolsuite/Monitor.
Intel's original intention to provide royalty-free use of RMX on its 386ex chip appears to have fallen by the wayside, leaving
RMX looking like an expensive option for most projects. Functional limitations such as the lack of C++ support and concerns
about post-sales technical assistance for smaller customers mean that RMX will probably not enter into the mainstream of
embedded software tools, except on very large capital-intensive projects.
The Embedded Toolsuite from Phar Lap however delivers a cost-effective route to using 32 bit PC compilers on an
embedded target while providing access to the full ANSI library functions. In fact, the TNT Kernel has the WIN32 API so that
it makes an embedded hardware look like a Windows PC without graphics. Future options include networking via TCP/IP.
The kernel takes care of the 386 protected mode set-up and allows the programmer to use the Microsoft and Borland IDEs
to create embedded programs quickly. The PharLap 386 locator, LINKLOC converts the .EXE file into an embedded
executable, while the monitor provides a remote debugging shell and protected mode startup code.
The TNT Standard Toolsuite offers perhaps the fastest way to get a 32 bit protected mode system up and running. For
applications with a strong real time content, the multi-threaded version is a true multi-tasking operating system based on PC
compilers with good real time performance. In both cases, an incorporation licence must be purchased for production.
Conclusions
The task of choosing a toolsuite for embedded, protected-mode x86 development is not a simple one; to take full advantage
of the latest embedded x86 CPU's, developers must break out of the limitations of 16-bitness and 1MB address space and
embrace 32-bit protected mode programming.
With PharLap's TNT Embedded Toolsuite , the programmer is shielded from the complexities of protected mode start-up by
an embedded monitor.
The same monitor, which is available in standard or multitasking variants, also reconstructs the WIN32 programming
environment on the target system, allowing developers to use familiar PC compilers.
In this way developers can not only produce new 32-bit applications for embedded targets, but can also move existing code
forward into the 32-bit world, while maintaining their investment in compiler technology and training .

The above sysnopsis is part of a larger document which reviews available tools for the x86 architecture.
The complete document is available on request from Hitex UK- please contact Louise Barnes on 01203 692066 Fax 01203
692131 email lbarnes@hitex.co.uk