Goto and simulating processors

Goto and simulating processors

[linnig]

> billwolf@hubcap.clemson.edu writes:
> From a recent article by blakemor@software.ORG.UUCP (Alex Blakemore):
> >    According to John Barnes [Programming in Ada p. 61]
> >      "The main reason concerns automatically generated programs ...
> >      [to] transliterate (by hand or machine) a program from some other
> >      language into Ada"
>    From what I've heard, as recently as October's Tri-Ada '88,
>    automatic translation is pretty well discredited as a software
>    porting technique.  

You might want to SIMULATE the execution of a microcode processor by
translating the microcode into Ada. The compiled Ada code would execute
much faster than it would if you interpreted the microcode each line at
runtime. Such simulated execution could be combined with the Ada code for
the controlling scalar processor to simulate the entire system. If the
microcode contained GOTO's, then the microcode GOTO could be translated
directly to an Ada GOTO.

Such a simulation would also be easy to port to another machine (assuming
an Ada compiler existed on that machine).


	Mike Linnig,
	Texas Instruments

Re: Goto and simulating processors

[William Thomas Wolfe,2847,]

From article <8901182220.AA10372@ti.com>, by linnig@skvax1.csc.ti.com:
> You might want to SIMULATE the execution of a microcode processor by
> translating the microcode into Ada. The compiled Ada code would execute
> much faster than it would if you interpreted the microcode each line at
> runtime. Such simulated execution could be combined with the Ada code for
> the controlling scalar processor to simulate the entire system. If the
> microcode contained GOTO's, then the microcode GOTO could be translated
> directly to an Ada GOTO.

     Any reason you can't use pragma INTERFACE, to C for example?

     (We're assuming efficiency is SOOOO critical that we absolutely
      must have the goto...)

> Such a simulation would also be easy to port to another machine (assuming
> an Ada compiler existed on that machine).

     True, but being able to port a very narrowly defined application
     area is a very small benefit compared to the big negatives presented
     by the use of the GOTO construct.  Besides, I don't think you'll find 
     much non-standardization with respect to the GOTO; either you
     have it or you don't, and it's so easy to provide that it's rarely,
     if ever, omitted from languages which provide it.  C or some other
     low-level language would be a more appropriate choice for what has
     got to be the lowest-level application imaginable...



                                             Bill Wolfe

                                      wtwolfe@hubcap.clemson.edu

Re: Goto and simulating processors

[Mark C. Adolph]

In article <4138@hubcap.UUCP>, billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) writes:
>      Any reason you can't use pragma INTERFACE, to C for example?
> 
>      (We're assuming efficiency is SOOOO critical that we absolutely
>       must have the goto...)

Yes, the reason is that I'm *WRITING IN Ada*.  Why should I have to go
out and buy a C cross compiler for my embedded processor, which may or
may not interface with my Ada compilation system, just to get
efficiency?  There is a world of computing outside of the VAX and the
Sun, and in much of that world, efficiency IS soooooo critical.  I think
that I prefer the code in my 747's wind shear detector to be both high
quality and efficient.  Why are they inherently incompatible?

>      C or some other
>      low-level language would be a more appropriate choice for what has
>      got to be the lowest-level application imaginable...

I believe that the whole point of this exercise is to standardize on
*one* language.  If a compiler cannot generate simple, efficient code
from simple, efficient Ada, then that compiler is due for rewriting.
And believe me, I've "had it up to my keister" with just such compilers
lately.

-- 

					-- Mark A.
					...uw-beaver!ssc-vax!adolph