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