From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,1a44c40a66c293f3 X-Google-Thread: 1089ad,7e78f469a06e6516,start X-Google-Attributes: gid103376,gid1089ad,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!news.germany.com!news.belwue.de!kanaga.switch.ch!switch.ch!newsserver.news.garr.it!newsserver.cilea.it!not-for-mail From: Colin Paul Gloster Newsgroups: comp.lang.ada,comp.lang.vhdl Subject: Embedded languages based on early Ada (from "Re: Preferred OS, processor family for running embedded Ada?") Date: 28 Feb 2007 17:20:37 GMT Organization: CILEA Message-ID: References: <1172192349.419694.274670@k78g2000cwa.googlegroups.com> <1172239820.896603.222120@k78g2000cwa.googlegroups.com> NNTP-Posting-Host: docenti.ing.unipi.it X-Trace: newsserver.cilea.it 1172683237 32194 131.114.28.20 (28 Feb 2007 17:20:37 GMT) X-Complaints-To: news@cilea.it NNTP-Posting-Date: 28 Feb 2007 17:20:37 GMT Xref: g2news2.google.com comp.lang.ada:9602 comp.lang.vhdl:7570 Date: 2007-02-28T17:20:37+00:00 List-Id: 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" 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.