Embedded languages based on early Ada (from "Re: Preferred OS, processor family for running embedded Ada?")

[Colin Paul Gloster <Colin_Paul_Gloster@ACM.org>]

I post from news:comp.lang.ada to news:comp.lang.vhdl .

Stephen A. Leake wrote in news:news:u649rx29a.fsf@stephe-leake.org on
news:comp.lang.ada for the benefit of Mike Silva:

"[..]

[..] FPGA development relies heavily on simulation,
which does not require real hardware."


A warning to Mike Silva: supposed simulators for languages chiefly
used for FPGAs often behave differently to how source code will
actually behave when synthesized (implemented) on a field programmable
gate array. This is true of cheap and expensive tools promoted as
simulators.


Stephen A. Leake wrote in news:news:u649rx29a.fsf@stephe-leake.org on
news:comp.lang.ada :

"[..]

Someone who can do both Ada and VHDL would be a very valuable person!"


A very euphemistic approach to stating that someone who could not do
one of Ada and VHDL after a few days with literature and tools, is
probably not good at the other of VHDL and Ada.


In news:pan.2007.02.24.22.11.44.430179@linuxchip.demon.co.uk.uk.uk
timestamped Sat, 24 Feb 2007 22:10:22 GMT, "Dr. Adrian Wrigley"
<amtw@linuxchip.demon.co.uk.uk.uk> posted:
"On Sat, 24 Feb 2007 07:27:01 -0500, Jeffrey Creem wrote:

> Stephen Leake wrote:
>
>> Someone who can do both Ada and VHDL would be a very valuable person!
>>
> I'm always surprised that VHDL engineers are not more open to Ada given
> how close the syntax is. The standard joke where I work is that VHDL is
> just like Ada except the capslock is always stuck on and comments are
> apparently forbidden ;)"


Just as one can find expert C++ programmers who lament what C++ code
from typical C++ programmers and typical C++ education are like, one
can find expert VHDL interlocutors who are not fond of typical VHDL
users. Such people who are so incompetent with VHDL are incompetent
with it because they are forced to use VHDL and they can get away with
not being good at it, so they are not likely to really want to use Ada either.


"I came to Ada from VHDL.  When I first encountered VHDL, my first though
was "Wow!  You can say what you mean clearly".  Features like user
defined types (ranges, enumerations, modular types,"


VHDL does not have Ada 2005's and Ada 95's mod types (
WWW.AdaIC.com/standards/05rm/html/RM-3-5-4.html
), unless I am mistaken.


" multi-dimensional
arrays) gave a feeling of clarity and integrity absent from software
development languages."


Apparently for many years, VHDL subset tools (the only kind of VHDL
tools which exist, so even if the language was excellent one would
need to restrict one's code to what was supported) used to not support
multi-dimensional arrays.


"So when I found that you could get the same benefits of integrity
in software development from a freely available compiler, it didn't
take long to realize what I'd been missing!  Ada is without doubt
the language at the pinnacle of software engineering, and infinitely
preferable to Pascal, C++ or Modula 3 as a first language in teaching."


Ada is good in the relative sense that it is less bad than something
which is worse than Ada, which is in no way similar to an absolute
statement that Ada is not bad. Unfortunately Ada (including VHDL)
allows

procedure Ada_Is_As_Unsafe_As_VHDL_And_GNAT_Will_Not_Even_Warn is
   value,Y:Integer;
begin
   if False then
      Value:=0;
   end if;
   Y:=Value;
end Ada_Is_As_Unsafe_As_VHDL_And_GNAT_Will_Not_Even_Warn;
   --GNAT is an abbreviation of "the GNU Ada Translator".

I do not know Modula-3 and Oberon. Do they allow such a trivially
detectable accident?


Dr. Adrian Wrigley wrote:

"But I have ever since wondered why the VHDL and Ada communities
are so far apart."


Sometimes they are not as ignorant of each other as they might
typically be. E.g. Ada 95's and the latest VHDL's permissiveness of
reading things of mode out may be just a coincidence, unlike the
syntax for protected types in IEEE Std 1076-2002 which is copied from
ISO/IEC 8652:1995 (however the semantics are not fully copied,
e.g. mutual exclusion is ridiculously stipulated in VHDL for pure
functions on a common protected object). It is true that the
communities are not always close, e.g. shared variables were
introduced in IEEE Std 1076-1993 and were very bad (but at least even
IEEE Std 1076-1993 contained an explicit warning against them). In my
experience, a person who has specialized in VHDL has heard of Ada but
has not been interested to read anything about Ada except in a brief
history of how VHDL had been started.


"  It seems like such a natural partnership for
hardware/software codevelopment."


A thing which may be perceived to be obvious to one might not be perceived to
be such by another. For example, from Jamal Guennouni, "Using Ada as a
Language for a CAD Tool Development: Lessons and Experiences",
Proceedings of the fifth Washington Ada symposium on Ada WADAS 1988:

"[..]

[..] On the other hand, our approach for hardware
description is also different from the one taken by Shahdad.
Indeed, we have stuck to the Ada language whereas Shahdad
[20] has developed a new language based on Ada called
VHDL (a part of the VHSIC program) dedicated to
hardware description and simulation. Moreover, we have
used the same language (i.e., Ada) for hardware and
software simulations whereas the VHDL language is used
for hardware descriptions only. This has several drawbacks
since it sets up a border between a software designer and a
circuit designer. It cannot benefit from the advantages connected
with the use of a single language during the whole
design process (e.g., use of the existing development and
debugging support tools).

[..]"

Don't get excited, Jamal Guennouni was writing about Ada for hardware
much as VHDL had been originally intended for hardware - that is: not
for automatic generation of a netlist. However, work on subsets for
synthesizable Ada has been expended. Now you may become excited, if
you are willing to allow yourself the risk of becoming disappointed,
after all if work was published on this in the 1980s then why did
WWW-users.CS.York.ac.UK/~mward/compiler/
get a publication in 2001 without citing nor even mentioning any of
the earlier relevant works of synthesizable Ada projects?


Dr. Adrian Wrigley wrote:

"  And there is significant scope
for convergence of language features - fixing the niggling and
unnecessary differences too."


That would be nice. However complete uniformity shall not happen if
things which are currently compatible are to maintain
compatibility. Does it really make sense to replace one
incompatibility with compatibility and at the same time replace a
different compatibility with an incompatibility? E.g. VHDL differs
from Ada in not allowing to specify an array's dimensions as
follows: array (address_type'range) if address_type is an INTEGER
(sub)type (making array(address_type) legal) but if address_type is a
(sub)type of IEEE.numeric_std.(un)signed it is legal to have
array(address_type'range) but it means something different because
VHDL (un)signed is an array type (making array(address_type) illegal).

Should Ada's attribute 'First refer to the lower bound of the index of
a type based on IEEE.numeric_std.(un)signed or to the lower bound of
the numbers which can be interpreted as being represented by such an
array? It is impossible to choose one or the other without a resulting
incompatibility.

In Ada 2005 and Ada 95, a mod type which represents a whole
number is treated not as an array type when applying attributes,
but in VHDL, IEEE.numeric_std.unsigned and IEEE.numeric_std.unsigned
are treated as array types when applying attributes, even though they
may be treated as whole numbers in other contexts. Mod types and
IEEE.numeric_std.(un)signed are used for logical either true or false
operators.

Even in Ada, an array of Ada Booleans is not identical to an Ada mod
type, and even in VHDL, IEEE.numeric_std.unsigned and INTEGER are not
identical, so why should a huge amount of effort be spent to integrate
similar or other aspects of Ada and VHDL?


"  Physical types,"


Why bother?


" reverse ranges,"


Stephen A. Leake responded in news:u7iu68eba.fsf@stephe-leake.org :

"[..] reverse ranges make things ambiguous, especially for slices of
unconstrainded arrays. So I don't want to see those in Ada."


Maybe. From the VHDL standard:
"[..]
[..] the following two block configurations are equivalent:
for Adders(31 downto 0) ... end for;
for Adders(0 to 31) ... end for;
[..]
Examples:
variable REAL_NUMBER : BIT_VECTOR (0 to 31);
[..]
alias MANTISSA : BIT_VECTOR (23 downto 0) is REAL_NUMBER (8 to 31);
-- MANTISSA is a 24b value whose range is 23 downto 0.
-- Note that the ranges of MANTISSA and REAL_NUMBER (8 to 31)
-- have opposite directions. A reference to MANTISSA (23 downto 18)
-- is equivalent to a reference to REAL_NUMBER (8 to 13).
[..]"

It is true that an illegal description can result by mixing up
directions, but could you please give a concrete example of how
directions can be ambiguous? The VHDL attribute 'RANGE returns
"The range A'LEFT(N) to A'RIGHT(N) if the Nth index range
of A is ascending, or the range A'LEFT(N) downto
A'RIGHT(N) if the Nth index range of A is descending", and similarly
'REVERSE_RANGE returns "The range A'RIGHT(N) downto A'LEFT(N) if the
Nth index range of A is ascending, or the range A'RIGHT(N) to
A'LEFT(N) if the Nth index range of A is descending." Similarly:
"NOTES
1 - The relationship between the values of the LEFT, RIGHT, LOW, and
HIGH attributes is expressed as follows:


                 Ascending range         Descending range
T'LEFT =          T'LOW                   T'HIGH
T'RIGHT =         T'HIGH                  T'LOW"


Dr. Adrian Wrigley wrote:

"configurations, architectures,"


It is true that we miss these in dialects of Ada not called VHDL, but
we can cope. An interesting recent post on how to not bother with the
binding of a component instance to a design entity of an architecture by
a configuration specification without sacrificing the intended benefit
of configurations and architectures is
news:54gnriF20p8onU1@mid.individual.net


Dr. Adrian Wrigley wrote:

" defered constants"


Ada 2005 does allow deferred constants, so I am unsure as to what
improvement Dr. Wrigley wants for this area. Perhaps he would like to
be able to assign the value with := in the package body like in VHDL,
which is not allowed in Ada 2005. Perhaps Ada vendors would be willing to
make Ada less like C++ by removing exposed implementation details from
a package_declaration, but you would have been better off proposing
this before Ada 2005 was finalized.


Dr. Adrian Wrigley wrote:

" and ultra-light
concurrency come to mind from VHDL."


In what way is copying concurrency from VHDL where it is not already
present in Ada desirable?


Dr. Adrian Wrigley wrote:

"  And general generics, private types,
tagged types, controlled types from Ada (does the latest VHDL have these?)"


No mainstream version of VHDL has these. Interfaces and tagged types might be
added in a future version:
WWW.SIGDA.org/Archives/NewsGroupArchives/comp.lang.vhdl/2006/Jun/comp.lang.vhdl.57450.txt


Stephen A. Leake responded:

"I haven't actually studied the additions in VHDL 2003, but I don't
think most of these Ada features make sense for VHDL. At least, if you
are using VHDL to program FPGAs.

[..]"

Why?

The latest IEEE VHDL standard, does not have these, but the IEEE VHDL
draft standard Draft IEEE P1076/D3.2, December 10, 2006 contains the
addition of subprogram and package generics but VHDL never had (and even
in the draft still does not have) generic instantiations in which the
parameter is a type (Ada83 had all of these kinds of generics). These
could be nice for FPGAs.


Dr. Adrian Wrigley wrote:

"Perhaps a common denominator language can be devised which has the
key features of both, with none of the obsolescent features,"


Perhaps. But people could continue with what they are using. From
Dr. SY Wong, "Hardware/Software Co-Design Language
Compatible with VHDL", WESCON, 1998:

"Introduction.
   This Hardware/Software (hw/sw) Co-
Design Language (CDL) (ref.2) is a
small subset of ANSI/ISO Ada. It has
existed since 1980 when VHDL was
initiated and is contained in IEEE 1076
VHDL-1993 with only minor differences.
[..]"


Dr. Adrian Wrigley wrote:

" and
can be translated into either automatically?"

Stephe Leake responded:

"Why would you want to translate them into each other? The semantics
of
VHDL are _significantly_ different from Ada. A VHDL process is _not_
an Ada task.

[..]"


Perhaps for the same reasons people generate Verilog files from VHDL
files, and vice versa.


Dr. Adrian Wrigley wrote:

"  Something like this
might allow a "rebranding" of Ada (i.e. a new name, with full buzzword
compliance), and would be ideal to address the "new" paradigm of
multicore/multithreaded processor software, using the lightweight
threading and parallelism absent from Ada as we know it. For those who
know Occam, something like the 'PAR' and "SEQ" constructs are missing in
Ada."


I really fail to see the relevance of multiple processors to
lightweight threading.

Apparently Verilog is used more than VHDL. Verilog apparently has very
little thought given to safe parallelism. (E.g. Jonathan Bromley on
2005 May 20th on news:comp.lang.vhdl :
"[..]

[..] Verilog's cavalier attitude to 
process synchronisation (in summary: who cares?!) is a 
major problem for anyone who has ever stopped to think about 
concurrent programming for more than about five minutes.

[..]")
Papers on multicore topics in the near term are more likely to contain
SystemC(R) or SystemVerilog boasts. Some people do not reason. I was
recently involved in one of the European Commission's major multicore
research projects in which SystemC(R) development was supposedly
going to provide great temporal improvements, but it did not do so
(somehow, I was not allowed to highlight this). Is this a surprise?
From 4.2.1 The scheduling algorithm of "IEEE Standard SystemC(R) Language
                                TM
Reference Manual", IEEE Std 1666  -2005, "Approved 28 March 2006 American
National Standards Institute", "Approved 6 December 2005 IEEE-SA Standards
Board", supposedly "Published 31 March 2006" even though the Adobe
timestamp indicates 2006 March 29th, ISBN 0-7381-4870-9 SS95505:

"The semantics of the scheduling algorithm are defined in the
following subclauses.
[..]
An implementation may substitute an alternative scheme, provided the
scheduling
semantics given here are retained.
[..]
4.2.1.2 Evaluation phase
From the set of runnable processes, select a process instance and
trigger or resume
its execution. Run the process instance immediately and without
interruption up to
the point where it either returns or calls the function wait.
Since process instances execute without interruption, only a single
process instance
can be running at any one time, and no other process instance can
execute until the
currently executing process instance has yielded control to the
kernel. A process shall
not pre-empt or interrupt the execution of another process. This is
known as co-routine
semantics or co-operative multitasking.
[..]
A process may call the member function request update of a primitive
channel,
which will cause the member function update of that same primitive
channel to be
called back during the very next update phase.
Repeat this step until the set of runnable processes is empty, then go
on to the
update phase.
NOTE 1.The scheduler is not pre-emptive. An application can assume
that a
method process will execute in its entirety without interruption, and
a thread or clocked
thread process will execute the code between two consecutive calls to
function wait
without interruption.
[..]
NOTE 3.An implementation running on a machine that provides hardware
support
for concurrent processes may permit two or more processes to run
concurrently,
provided that the behavior appears identical to the co-routine
semantics defined in
this subclause. In other words, the implementation would be obliged to
analyze any
dependencies between processes and constrain their execution to match
the co-routine
semantics."

Anyone stupid enough to choose C++ deserves all the inevitable
woes. Especially as many of the involved parties did not even know C++
so allowable compilers were required to be restricted to a set of
compilers which are not conformant to the C++ standard as much of the
code was not written in genuine C++. This is not a surprise as the
Open SystemC Initiative's SystemC(R) reference implementation of the
time was written in an illegal distortion of C++.


Dr. Adrian Wrigley wrote:

"While the obscenities of C-like languages thrive with new additions
seemingly every month, the Pascal family has withered.  Where is
Wirth when you need him?

(don't take it that I dislike C."


I dislike C.

"  Or assembler.  Both have their
legitimate place as low-level languages to get the machine code
you want.  Great for hardware hacking.  Lousy for big teams, complex code)

One can dream..."

C is not great for hardware hacking.