Using microcomputers for engineering calculations

Using microcomputers for engineering calculations J. M. N E L S O N

Department of Civil En.qineerin.q, University of Sotahampton, Southampton S09 5NH, UK

The article examines the difficulties and advantages afforded by microcomputer systems in engineering analysis and design applications. In particular, the speed and storage requirements of several Z-80 language systems in handling matrix operations characteristic of structural engineering problems are compared. The trends towards ROM-resident design and analysis packages and multiple processor computers are presented and the reasoning behind their introduction discussed. PROGRAMMING MICROCOMPUTERS E N G I N E E R I N G CALCULATIONS

FOR

Making the decision as to which programming language(s) are to be used in developing programmes for engineering calculations is a critical step upon which the practicability of using a microcomputer system hinges. While the choice (on the surface) seems to be much the same as it is in the case of minicomputers, there are some substantial differences. In most instances, at least at present, the practical solution will be to use Fortran, Basic, or assembly language, or some combination of them. Although other languages have been postulated, implemented, and even used for engineering applications, few engineers and scientists are prepared to diverge from the more or less universally recognized high level languages for algorithmic coding. In addition, the level of software technology supporting these languages, and the comparative level of standardization make them attractive. When considering the development of microcomputer programs, the key features differentiating them are intrinsically tied in with the economics of microcomputer development. Because the advantages of microcomputers are largely economic, the level of investment in system software design is correspondingly less than it is for minicomputers, and most certainly for mainframe computers. Not only is the software investment smaller, but also the market consists of consumers who wish to make the minimum investment, often meaning that they will prefer, for instance, ROM based Basic interpreters rather than Fortran compiling microsystems requiring considerably more system software such as linkers, loaders, libraries, and debuggers, not to mention expensive mass storage devices. What is often of more interest to them is the fundamental capabilities of a language, i.e. "Can it do this?" rather than "How efficiently can it do this?". Unfortunately, both Basic interpreting systems and Fortran compiling microsystems have widely varying capabilities, storage requirements and other limitations, and rates of processor time consumption even when developed for the same computer. The differences in

0141- I195/80/010009-0452.00 ©

1980 CML

Publications

organizational structure, which relates to ROMability, compartmentalization, and architecture independence are quite important. We will attempt to study some of the aspects as they compare in one of the most suitable microcomputer environments, the Z-80 based computer. The most cogent arguments in favour of developing Fortran engineering programs for microcomputers are the general availability and the relatively easy transportability of Fortran programs from mainframes and minis to microcomputers, and the speed at which compiled code executes by comparison to interpreted Basic. While the first point is a perfectly sound one, and must be taken into account when deciding how to develop a certain range of application programmes, the latter point is substantially less important, in practice, than it appears. It is true that, in general, Fortran code runs at five to twenty times faster than equivalent Basic programmes in currently available microcomputers, however, one finds that the majority of time in most scientific or engineering calculations is taken up by an isolated set of highly repetitive operations. In either finite element or boundary element analysis, for instance, almost all the significant time consumption occurs during the inversion (or solution) of a large, matrix equation. Particularly when the data are input interactively, the time required to set up the equations is inconsequential. Clearly then, if subprograms to perform such operations as matrix triangulization and backsubstitution are coded directly in machine language to be called from a Basic (or Fortran) program, the result will be to effectively reduce the total time requirement of the program. This is especially true in the case of microcomputers which have a quite large register set such as the Z80, because Fortran compilers (on minicomputers as well) rarely have the cleverness to utilize registers effectively, preferring to generate code which is largely independent of the program's logic (i.e. the same code can be generated for a Fortran statement independent of the surrounding statements). On the Z-80 computers, machine code programmes execute at roughly twice the speed of the equivalent Fortran on average. Nevertheless, writing machine language routines to perform operations such as the evaluation of obscure trancendental functions or solving a matrix equation with some particular symmetry or sparseness property can be a tedious occupation, particularly for the engineer with little or no background in assembly language or any kind of machine-dependent programming. Fortunately, firmware (software embedded in ROMs) packages to perform these tasks are becoming available for certain hardware/software system configurations. There is, however, a tremendous amount of work to be done before these will be easily accessible to most microprocessor systems, and the variety of high level language recognizing programs. Without a doubt most engineering software which is

Adv. Eng. Software, 1980, Vol. 2, No. 1 9

easily available is written in Fortran and runs on a mini or mainframe computer. As mentioned before, microcomputers, although capable of compiling and running Fortran programmes (given enough mass storage), are usually utilized in situations where the minimum cost per capability is .desired, often by sacrificing complete machine independence and transportability in favour of cheap, easy to use, and, in particular, highly interactive systems interpreting Basic. Nonetheless. several microcomputer vendors and some of the software houses are supplying increasingly practical and useable microFortrans, and it is certain that many microcomputer applications software will continue to be developed using this language. Intel's recently introduced Fortran-80, for instance, besides exceeding the 1977 ANSI Fortran standards, has programmability matching the best of the mini Fortrans. Its requirements are not too extravagent - - 64 kbytes of RAM and two floppy disc drives minimum'. It seems clear that three distinct avenues exist along which engineering software will be obtained for microsysterns. The large scale microsystem user may simply transfer existing Fortran programs from larger computers and modify them to suit this particular configuration and hardware. In srpailer, 'personal' microsystems, engineers will tend to convert existing Fortran programs into Basic, since the effort required (especially for engineering software) is minimal. A third avenue for software support will be the development of highly efficient, machine coded engineering software libraries embedded on ROMs (Read Only Memories), specifically in cases where mathematically formalizable operations are often being undertaken. The engineer or scientist will write simple programs to essentially join the various routines to form a particular calculation. Among the most suitable engineering analysis types which will benefit from this technique are finite element and boundary integral element modelling methods, since they are directly formalized mathematically, and possess a high degree of modularity. In addition, simplified versions of complete engineering packages such as PAFEC, FEHPOL, OASYS, etc. will become available for microcomputer systems. As is true with language systems, these naturally divide themselves into two cati~gories, the disk-based packages which run on larger, general purpose microsystems, and the ROMbased packages which are used for repetitive calculations such as those in engineering design. ROMmed packages, although often compared unfavourably with diskresident packages, especially by computer orientated people, nevertheless have a considerable attraction for the engineer in that they are basically incorruptible, reliable, fast to access, and require no interfacing or maintenance. In some ways, their inflexibility is even an asset, as any engineer who has suffered through frequent operating system upgrades can tell you. (It seems that both micro, mini, and mainframe systems programmers are born with a burning desire to modify the file management part of an operating system at the drop of a hat, usually rendering previously accessible codes unreadable or unuseable without some modification, conversion, or complete regeneration.) Also,of importance is the fact that engineering calculations tend to be of a specialized, rather than of a general purpose computing nature, and therefore are convenient to have directly resident within the computers addressable (or bank selectable) memory range.

10

Adv. Eng. Software, 1980, Vol. 2, No. 1

P E R F O R M I N G ENGINEERING CALCULATIONS An important factor to consider when performing engineering calculations on microcomputers is the speed at which floating point arithmetic operations are carried out. Since most calculations are heavily dependent on floating point arithmetic, considerable attention is made to ensure maximum optimization of arithmetic operations. To speed up floating point operations, a specialpurpose external floating point device is sometimes used. These speed up the operations usually by using a faster kind of circuitry than conventional microcomputers use. In addition, they can often run asynchronous[y and concurrent with the central microprocessor. This allows floating point operations to be partially overlapped with other non-floating point operations 2, a technique called parallel processing. Another similar technique which has not yet been fully explored is the use of multiple microprocessors which operate simultaneously. In practice, there are few examples of the latter technique being employed. One exception, however, is the scheme developed by Loewer 3 which allows multiple Z-80 microprocessors to share the burden of calculation in a single microsystem. More commonly used by S-100 bus compatible microcomputers is the North Star Floating Point Board, a special purpose floating point processor of the aforementioned type. At present, this board is the only significant contender for the microcomputer using engineering market, although it is likely that others will become available. Among its features is selectable precision flom two to fourteen digits, As mentioned later, this board has some serious, although easily rectifiable drawbacks, namely the way it fetches and returns data to the microprocessor. Using a floating point processor is not the only way to increase computational speed and therefore commercial practicability. It is often very difficult to pin down the key factors that affect time consumption on a particular microcomputer system, even for programs whose logic has been completely optimized. Different languages, and different versions of the same language consume time at varying rates, not necessarily directly relateable to either the amount of computation being done or the precision of numeric representation scheme. Although difficult to make generalizations about, a few experimental observations can shed some light on the range ofefficiency to be expected. A fairly simple matrix inversion algorithm has been chosen and the time requirements compared for performing the inversions using several languages, wilh and without an external floating point unit on the Z-80. To relate these to less powerful microprocessors and mainframe computers, the two bottom statistics have been included (mainly for general interest) in Table 1. This shows that (as a rough estimate) engineering programs written in Basic execute twenty times more slowly than their machine code equivalent and in Fortran execute at about half the speed. It is interesting to study the tradeoffs between storage and time consumption for typ'ical engineering calculations. Consider the inversion (in place) program. Its time and storage requirements are typical of boundary element calculations, where the setup time is insignificant and the matrices have no symmetry or bended character. The storage of the program (if using a typical BCD number representation) is given by:

S--(½P+ l)C2

Table 1.

Language

(such as matrix operations) is written in machine code (or compiled from another language, i.e. Fortran).

NORTH Time Digits Star required Computer precision F.P. Board? for 30x 30

3K Control Z80 Basic Cromenco 16K Z80 Basic 8K North Star Z80 Basic Cromenco 16K Z80 Basic 16K S-Basic Z80 Cromenco Z80 Fortran Z80 Machine Z80 code Commodore PET 6502 Basic IBM Fortran IBM360

6

Yes

930

14

No

572

8

Yes

540

6

No

510

8 7

Yes No

456 62

8

Yes

27

9

No

837

8

No

DIFFERENCES WITH MICROCOMPUTERS

0.2

Table 2. Language

3K Control Basic 16K Cromenco Basic 8K North Star Basic 16K Cromenco Basic 16K S-Basic Cromenco Fortran Z-80 Machine code

A

P

0.035 0.021 0.020 0.019 0.017 0.002 0.001

6 14 8 6 8 7 8

where C is the number of rows in the matrix and P is the number ofdigits of precision in the number representation being used. The time required for full inversion is given by:

T=AC 3 where A is an efficiency factor which depends on the language and the hardware used. In the case of heavy floating point arithmetic dependent programs one can further divide the efficiency A into a floating point calculation part and a general overhead part which is unrelated to the precision of the number representation. Assuming that floating point A D D s and S U B T R A C T s occur roughly as often as M U L T I P L Y s and D I V I D E s we can write:

AND

The differences already discussed between larger computer systems and microcomputer systems can be put in the general category of architectural dependence. In other words, the limitations of programs and user efficiency are related to the physical configuration and implementation of the microcomputer system. There are other architecturally dependent aspects of microcomputer usage which arise when developing reasonably sophisticated engineering programs. The first is the use of R O M resident data or code. When using externally available R O M m e d libraries containing engineering related software, the organizational problems will have already been solved. When the engineer is developing and R O M m i n g programs, however, particularly when programming in high level languages such as Basic or Fortran, there are several possible complications. For instance, it is necessary to completely separate the non-volatile data and the program from the arrays, variables, and even temporary runtime storage areas. While some compilers and interpreters allow sufficient user control of the process to do this explicitly, many do not. M a n y Basics, for instance, automatically place variable and array storage immediately after the Basic text, a restriction which makes the programme u n R O M m a b l e unless some particular tricks are employed. Many Fortrans allow some user choice as to where in memory storage is allocated, but as often as not this is limited to blank C o m m o n variables or only u n C o m m o n e d variables or excludes variable Formats. There are numerous other possible complications which are architecture dependent. Many are hardware related and therefore difficult to generalize about. A typical example of a hardware complication as it appears in a Z-80 system using the North Star Floating Point Board can be given. This floating point processor uses two addresses in the address range (hexadecimal) D O O O D F F F to accept its arguments and return status of the

1000

I

o

I

i

t

S $ /

300

.~/.~7//Z~\,~'.oe

200

A =Ayp(P)(P+ 1)+A o Typical values of A for the Z-80 are given in Table 2. Only in the case of Cromenco Basic can we actually separate the floating point arithmetic time from the Basic interpretation and other overheads time since it is the only language system tested with an easily variable rate of precision. We find that: Asp = I. 19 x 10- s and A o = 0.0185 which implies that for the six digit precision case 2.6)o of the total time was spent in floating point arithmetic and in the case of the 14 digit precision only 1 1.9';~0 of the time was spent on floating point operations. Clearly then, for Basic programs the investment in floating point hardware is unjustified unless the calculational part of the program

MAINFRAMES

~

~

~

~

~

_~/

i

I

I

/

~

,,oo

,

7®o%ooo., ooo

lO 10

20

30

40

50

60

80

100

Number of rows i n n ~ t r i x

Fiqure I.

Z-80 matrix inversion time vs. number of rows

Adv. Eng. Software, 1980, Vol. 2, No. 1

11

operation. By doing so, it not only disallows the use of any other memory in that 4 Kbyte range, but also limits the size of the contiguous data area used by either Basic or Fortran programs (even the cleverest language recognizing programs dislike discontiguous data areas). In addition, because it retrieves its arguments from the computer by 'peeking' on the main bus, it cannot be used by programs residing on certain banks of memory or with data stored in memory which happens to be on the same board as the processor and therefore bypasses the main bus. To the user, this means that programs must be (1) in the right place, and (2) must somehow avoid using certain address spaces (easily done in machine code, but not so simple in a high level language). Whereas on a large system, the two key limitations are time and storage, in practice, architectural complications often place more arbitrary restrictions on the way programs will operate in microcomputers. Microcomputers which are chosen for engineering calculations will usually have the capability of addressing quite a large amount of primary storage (memory). Typically, 64 K or 128 Kbytes of memory are directly addressable, and in some cases there are bank select features, enabling any one of a large number of these 64 K or 128 K banks of memory to be selected by the program. When one considers the requirements of any semiinteractive or fully interactive engineering program, it becomes apparent that the time requirements are more limiting than the storage requirements on microcomputer systems. This is further confirmed by the rapidly falling price of microcomputer memory. Consider, for instance, a

12

Adv. Eng. Software, 1980, Vol. 2, No. I

typical, fairly sophisticated engineering program to 6alculate the transient dynamic response of an arbitrary two dimensional or axisymmetric elastic-plastic structure using the finite element method. The storage requirement for this calculation using Microhondo is given by: S = ( 1 2 N + 18E+32M+5B+2P) floating point numbers where N = t h e number of finite element nodes, E = t h e number of finite elements, M =the number of different materials, B=the number of pressure boundary conditions, P = t h e number of points in the pressure-time history. Clearly, a large number of practical problems (impacts, for instance) can be solved with S=4000. On a Z-80 computer with 8-digit precision, this implies a total volatile memory requirement of only 20 Kbytes, which is less than one-third of addressible memory (the other 3 of which would be partly filled with the program). Fully three-dimensional problems require correspondingly more memory, but, on the whole, it is the execution time which becomes prohibitive.

REFERENCES I

Hemenway,

J.

The

8080

gets

a

"'full-blown"

Fortran,

MiniMicroSystenls October 1978, pp. 78-80 2

Nelson, J. M. Parallel processing in Fortran with floating point hardware, Software Practice and Experience 1975, 5, 65 3 Locwer. B. TheZ-801n Parallel, BYTE July 1978. pp. 60-64. 174176