Solving The 386EX Software Dilemma
Solving The 386EX Software Dilemma
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.
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 [email protected]