New HDL Compiler Project
Marty Stanquist
your inputs on the possibility of extending the Open Watcom platform to
include support for Hardware Description Languages, also known as HDL's,
particularly for the languages Verilog, VHDL, and Ada. Ada is not
technically an HDL, but it is an effective language for embedded systems
programming and for implementing a VHDL compiler front end. I'd like to
outline a new project to extend Open Watcom to the arena of multi-language
embedded system simulation. In the discussion below, I will outline the
rationale, scope, forum, and timeframe for the project and provide some
useful resource links. I would like to request that you review the
discussion and comment on its nature, usefulness, and implementation.
Marty
Rationale
-------------
As embedded system development progressed throughout the 1970's and 1980's,
much of the product development cycle was spent working in the lab with a
hardware breadboard connected to a logic analyzer and a microprocessor
emulator. After weeks of lab development refining the prototype, many more
weeks were usually spent testing the prototype in the field under real world
conditions. This field testing often resulted in additional changes that
required additional lab testing. As a result, hardware development cycles
were often measured in terms of months and years instead of in terms of
weeks. As technology progressed throughout the 1990's and 2000's, computer
simulation in a number of different areas (circuit, logic, mechanical,
fluid, electromagnetic, etc.) reduced or completely eliminated much of the
required lab work. Designs were simulated, prototypes were fabricated,
verification tests were run, and the final prototypes were sent straight to
the field for real world testing. With designers having access to fast
simulators, the cycle times needed to correct field issues was significantly
reduced. Simulation has helped companies reduce their development schedules
by many months. As we move forward into the current decade, with multi-core
PC's loaded with gigabytes of ram and terabytes of disk, companies are
beginning to do most of the real world field testing right on the computer
using large, highly sophisticated physical models. These physical models
often contain hundreds of thousands (sometimes millions) of lines of C++ or
Fortran. An example illustrating the use of large physical modeling is how
UAV's are simulated flying through windy mountain passes and canyons with
all the engines, propellers, servos, ailerons, radars, and flight processors
actively running. Additionally, cars are now simulated in skid and crash
tests with the engine, drive train, suspension, anti-lock brakes, fuel
injection, and steering systems all fully engaged. These car models often
include a simulated driver or crash dummy as well. And not to be forgotten,
Nasa has simulated every Space Shuttle and deep space mission in this manner
for many years. Full real world system simulation has dramatically reduced
product development times by eliminating the need for extensive lab and
field testing. It is evident that we are entering the age of multi-language,
multi-disciplinary system simulation in which products go straight from the
simulator to a field evaluation unit then right to production. The need for
hardware simulation capability in this process, namely having access to
Verilog, VHDL, and Ada compilers, in addition to support for C, C++, and
Fortran is thus a mission critical requirement. This is the rationale for
pursuing the project.
Scope
--------
I am anticipating three phases of implementation.
The initial phase will have the following objectives:
* Develop individual compiler front ends for Verilog (using C) and VHDL
(using Ada)
* Develop a sufficiently complete Ada compiler for compiling the VHDL
front end
* Integrate Verilog, VHDL, and Ada compilers into the existing OW
framework
* Develop initial C interface libraries (VPI/VHPI) for Verilog and VHDL
Verilog, VHDL, and Ada will be separate, individual compilers that will
generate object files compatible with the existing linker, debugger, and
other tools. Ada has merits of its own, but it is syntactically very close
to VHDL and is an effective language for implementing the VHDL compiler
front end. It would be worthwhile developing a minimal Ada compiler just
capable enough to compile a VHDL front end written in Ada. Verilog is
syntactically close to C. I believe the existing C compiler front end could
be copied and easily modified to parse Verilog. The intent is to have all
three compilers use as much of the existing code generator software as
possible and to have Verilog and VHDL share a common runtime library that
will include a logic simulator. A logic simulator is a program that
evaluates and propagates logic switching events throughout a hardware design
using a data structure called an event wheel, or more technically a circular
event queue. Both Verilog and VHDL will additionally have separate runtime
libraries for C interface functions (VPI for Verilog, VHPI for VHDL) that
will need to be developed. The compiler will parse each HDL design file (.v
or .vhd), converting it directly into an object file (.obj). A simulation
executable file (.exe) is then created by linking all the HDL object files
(.obj) with a common simulator runtime library (.lib). This is what is
referred to as compiled simulation. The resulting simulation executable
(.exe) can be run either by itself to produce text and binary output files,
run along with a waveform viewer to produce real-time signal traces, or run
within the debugger along with the HDL and C/C++/Fortran source files in
what is called source level debugging. Since Verilog and VHDL object files
(.obj) will be compatible with all the other OW tools, C, C++, and Fortran
behavioral models will be able to be linked along with the HDL design files
then simulated and debugged together.
The second phase will have the following objectives:
* Develop a common logic synthesis back end for Verilog and VHDL
* Extend Verilog and VHDL compliance to the latest standards
* Further develop the C interface libraries (VPI/VHPI) for Verilog and
VHDL
* Develop a waveform viewer and a schematics editor for evaluating output
results
In synthesis mode, logic synthesis routines will replace the machine op-code
optimization routines in the existing compiler back end. Logic synthesis
works by generating and manipulating either logic gates or structures called
the configurable logic blocks of field programmable gate arrays, known as
FPGA CLB's. This is in contrast to generating and manipulating the cpu
op-codes that are processed by the existing compiler back end. Logic
synthesis algorithms are somewhat related to the existing op-code
optimization algorithms in that they modify the gates or CLB's generated
under the constraints of size and speed, or more specifically the
constraints of circuit area and logic delay. Synthesis algorithms differ in
that they use a different data structure called a binary decision diagram,
also known as a BDD, during the optimization process. The compiler parses
the HDL source files (.v or .vhd) and presents the synthesis routines with a
list of intermediate symbols representing the HDL design. The set of
existing intermediate symbols will need to be extended to include objects
like modules, processes, and signals that are present in HDL designs but are
not currently supported by the C, C++, and Fortran standards. The synthesis
routines convert these intermediate symbols into BDD's that are then
manipulated based on area and delay constraints provided for the hardware
design. Once optimized, the BDD's are then either converted to object files
(.obj) for gate level simulation or are converted to a hardware net-list for
integrated circuit (IC) or field programmable gate array (FPGA)
implementation. A hardware net-list is a listing of all the logic device
inputs and outputs along with all the logic signals interconnect them. In
the last stage of logic synthesis, referred to as retargeting, one must
choose a specific logic family or FPGA device from a given hardware vendor.
The vendor's specific device, or target library will include all the gate
and/or CLB definitions, the gate and/or CLB pin-outs, and all the
predetermined timing delays for the particular logic family or FPGA device.
In addition to processing the vendor timing delays, the final synthesis
routines will also request physical wiring delays that are generated by an
external IC or FPGA layout tool. This external delay processing, known as
timing back-annotation, is implemented using a timing file called the
standard delay file (.sdf). Gate level simulation takes into account all the
vendor target library delays and all the wiring delays determined by
external physical layout tools. The C interface libraries VPI for Verilog
and VHPI for VHDL will also need further enhancement. Additionally, since
the Verilog, VHDL, and Ada standards are currently in flux, much like those
for Fortran, additional work will be needed to update the compilers to the
latest specifications. Verilog is specified by IEEE 1364, VHDL by IEEE 1076,
and Ada by ISO/IEC 8652.
The third phase will have the following objectives:
* Add code generators and simulation models for embedded microcontrollers
* Add virtual system emulation and debugging support
* Add static timing capability to the logic synthesis routines
* Further enhance Ada language compliance and support
To augment the system's ability to simulate and debug embedded software,
code generators and simulation models will be developed for common embedded
microcontrollers, such as those in the 68K, Mips, and Arm families. Of
these, I suspect that Arm support will be a priority. The goal will be to
cross-compile the real-time source code to a given target cpu then engage
the source level debugger while the machine code executes on a Verilog or
VHDL simulation model of the target microcontroller. Since most embedded
systems have flash memories, UART's, timers, external logic, A/D and D/A
converters, buttons, displays, Ethernet and USB ports, and a real world
external environment, simulation models of these common components and
support for a built-in virtual machine environment (similar to QEMM) would
be both highly useful and desirable. Having all this support inclusive to
Open Watcom would be a major objective. Additionally, further system
enhancements will include adding static timing analysis capability to the
logic synthesis routines and further augmenting Ada language compliance.
Static timing analysis is a back end process that computes the worst case
timing delays through a gate logic network determining if critical set-up
and hold-time requirements are met for the flip-flop storage elements. This
is an analysis technique that eases the workload of verifying timing
requirements for full gate level simulations (most often a daunting
exercise). Static timing analysis has the ability to analyze a full gate
level design for the extremes of voltage and temperature, a technique known
as 4-corner testing.
Forum
--------
As the project moves forward, we are considering establishing a new
newsgroup to facilitate further discussion. This will be the news group:
openwatcom.users.hdl
Moving forward, I expect to be an active participant in the .contributors,
.hdl, and .fortran news groups while being generally available in chat room
#watcom at irc.freenode.net in the evenings and weekends CST US.
Timeframe
--------------
I would like to begin working on the project definition this fall while
coding efforts are underway for Fortran 2012. Phase 1 coding for the Verilog
and VHDL compilers could commence sometime after the OW 2.0 release this
spring. Coding for phase 2 and 3 is probably going to take a full year after
that. The coding priority right now is to complete Fortran 2012 for
integration into RC1 early next year.
Links
-------
Here are a few links that I hope you will find useful.
Hamburg VHDL Archive
http://tams.informatik.uni-hamburg.de/research/vlsi/vhdl
IEEE VHDL P1076 Working Group
http://www.eda.org/twiki/bin/view.cgi/P1076/WebHome
EDA Industry Working Groups
http://vhdl.org
GHDL (Gnu VHDL) Project
http://home.gna.org/ghdl
FreeHDL & Savant Projects
http://www.freehdl.seul.org
http://secs.ceas.uc.edu/~paw/savant
IEEE P1364-2005 Working Group
http://www.verilog.com/IEEEVerilog.html
Verilog Dot Com
http://www.verilog.com
Icarus Verilog
http://iverilog.icarus.com
Veriwell Verilog
http://sourceforge.net/projects/veriwell
MVSIS Project (Berkeley)
http://embedded.eecs.berkeley.edu/Respep/Research/mvsis
ABC Project (Berkeley)
http://www.eecs.berkeley.edu/~alanmi/abc
Ada Standards
http://www.adaic.org/ada-resources/standards
Boeing Flies on 99% Ada
http://archive.adaic.com/projects/atwork/boeing.html
-----------
Olafur Gunnlaugsson
that except good luck.
When it comes to ada however I would like to pipe in a bit, it is a bit
complex to implement, I personally know 2 such projects that never got
finished despite having finance and people behind it etc., and a number
of projects that did get finished were a bit "lacking" to say the least.
The only working open source implementations had companies and finance
behind the development.
Although originally designed to be safe the complexity of ada is such
that it has been rejected for some safety concious tasks precisely
because of that, mathematically proving a solution as safe was deemed to
be an impossible task, parts of the European high speed train security
systems are written in the terminally obscure language variant
Safe-Modula 2 for that reason, i.e. very similar to ada but
infinitesimally simpler thus much less work to prove and in fact it was
deemed less work and thus safer to implement a compiler from scratch
than to use an existing ada compiler
If I may I would like offer 2 alternative proposals:
1) Implement an Oberon-07 front end to Watcom from scratch using the
Wirth book and possibly some code as the basis, it is a very simple but
very functional language, I know of at the least 4 people that have made
complete compilers for 3 different processor architectures from that
source in a matter of weeks/months *on their own, in their spare time*.
After that implement ada in steps from that front end, Oberon and Ada
are in some respects very different languages, however the basics are
the same, they are both Pascal derivatives and the underlying concepts
are very similar and in many instances the same.
The complexity of implementing ada has meant that there are out there a
number of sub-set that are reasonably well defined and function on their
own as full programming languages that could function as stepping
stones, e.g. define a series of functional ada sub-sets of incremental
complexity that can be used and tested on their own until you reach a
full ada implementation.
Doing this you will in addition get at the least one language extra to
the Watcom project which may be a boon or a detraction, mileage may vary
If the oberon 4 Debugger could be somehow hijacked into the project even
better, it is the simplest most functional debugger I have seen but I
man not sure about what license it was released under
http://www.inf.ethz.ch/personal/wirth/Articles/Oberon/Oberon07.Report.pdf
The oberon-07 language report
Oberon p0rn
2) Take the BSD licensed Pascal and/or Modula-2 front-ends from the
Amsterdam Compiler Kit and port them to Watcom and then build from them
as above. They are archaic but perfectly functional or at the least the
M2 one was when I looked at it a few years back, in fact the maintainer
of the ACK has suggested that someone actually does that as he is
occupied with updating it for use with C frontend and x86 backend these
days since that is what the Minix project needs and the 2 front endes
are not likely to make it to the 6.0 version of the system.
Olafur Gunnlaugsson
Peter C. Chapin
> When it comes to ada however I would like to pipe in a bit, it is a bit
> complex to implement, I personally know 2 such projects that never got
> finished despite having finance and people behind it etc., and a number
> of projects that did get finished were a bit "lacking" to say the least.
or C++ these days. For fun I've started my own Ada implementation in
Scala. See:
https://www.assembla.com/code/augusta/subversion/nodes
http://augusta-notes.blogspot.com/
This project is in the very early stages; there is essentially nothing
there right now. Due to other pressures on my time I don't expect to
make any significant progress for a while but to give myself at least a
little structure I have set a release date of December 31, 2020.
When I started thinking about my project I considered attaching it to
Open Watcom. I decided against that for several reasons:
1. I don't like building compilers in C. It seems to me that C is not
well suited to that task. Open Watcom is (mostly) in C not because it's
the best choice technically, but rather because it was the only
reasonable choice at the time. I do have experience building compilers
in Scala (my dissertation project is a compiler written in Scala) but I
don't feel like I can impose that language and associated environment on
Open Watcom.
2. I want to use LLVM as a back end. Bringing LLVM into Open Watcom
would be a worthy thing to do but adding that step to my project would
only make my already ambitious project even more ambitious. Also,
frankly, I'm not sure where Open Watcom will be in 2020.
3. I want to use more modern tools for documentation, testing,
continuous integration, and so forth.
> Although originally designed to be safe the complexity of ada is such
> that it has been rejected for some safety concious tasks precisely
> because of that, mathematically proving a solution as safe was deemed to
The SPARK subset of Ada is used for safety critical systems in a number
of contexts. It is possible to mathematically prove the correctness of
programs using SPARK (for some suitable definition of "correctness"). I
ought to know; I use SPARK daily in connection with a project I'm
working on at Vermont Technical College.
Full Ada is also used in a number of safety critical contexts, such as
flight control systems on various aircraft, to name one example. In any
case it is far easier to verify programs in Ada than in C or even C++,
but that's not saying much as both C and C++ are highly unsafe. It's
more interesting to compare Ada vs C with advanced tool support, or to
compare Ada vs some other modern language designed for robust systems
such as Eiffel. Comparing Ada directly with C is like kicking a man who
is down.
Peter
Peter C. Chapin
to digest it. However, I did want to comment on one thing now...
On 2011-10-09 15:50, Marty Stanquist wrote:
> With next generation Fortran development underway, I would like to
> request your inputs on the possibility of extending the Open Watcom
> platform to include support for Hardware Description Languages, also
> known as HDL's, particularly for the languages Verilog, VHDL, and Ada.
> Ada is not technically an HDL, but it is an effective language for
> embedded systems programming and for implementing a VHDL compiler front
> end.
compiler in any language regardless of the language being compiled. Thus
a VHDL compiler could be written in, for example, C. The syntactic
similarity between VHDL and Ada means that the parser used by a VHDL
compiler would probably have some similarities to an Ada parser. Outside
of that would there be any other commonalities between VHDL and Ada? The
semantics of the two languages must be quite different, yes?
As part of my Augusta project I will have an Ada parser. Could that
parser be used as a starting point for a VHDL parser? Maybe. However, my
parser uses the ANTLR parser generator and is ultimately in Java. These
tools are not part of the Open Watcom ecosystem so a VHDL compiler in
Open Watcom would probably need a different parser than the one I'm
building.
Peter
Kevin G. Rhoads
>semantics of the two languages must be quite different, yes?
IMHO -- No. I've been coding since the late 60s, assembler and Fortran consistently with
other languages coming and going (e.g., COBOL, PL/I, C, Pascal, AWK, Lisp &c)
Recently we've starting going to FPGA based systems (instead of 8051 style) and I've been
using Xilinx ISE to "compile" VHDL into bit-files and FlashRom programming files. One
of the students (senior honors thesis, then continuing with a Master's) did the base work,
and I inherited the project.
HDLs and programming languages often have very similar syntax, but the semantics are radically
different. HDLs describe hardware, i.e., circuitry. Parallelism is automatic unless sequentiality
is forced upon the implementation. Issues such as meta-stability and race-conditions need be
considered. (OK -- yes, in various real-time situations, software needs to consider race conditions,
but ...).
Some similarity does exist, but, the rather good agreement and similarity in syntax tends to be
deceiving, as the semantical similarity is much less.
I've never done much with simulation languages (e.g., Simula) but the little I know of them I
would expect their semantics to be closer to that of HDLs than either procedural or functional
programming languages. Perhaps OO stuff also has more semantic similarity. But the two big
HDLs, VHDL and Verilog, are Ada-like and C-like (respectively) in syntax. Syntactically neither is
very like any OO (with which I have but passing familiarity).
So, (again emphasizing MHOO), hacking a parser together, fairly straightforward. Expanding the intermediate for new constructs, fairly straightforward. Back end -- big time headache, highly
non-trivial -- and for targeting ?what? Xilinx? Altera? any of the bit players? And which
families?
Plus, is the IDE to be extended to allow for schematic display from HDLs? Schematic capture? How
about state machine diagrams -- generation and display? Input? <arrgh>
Get Xilinx ISE (webpack version is free) and play with some of the example projects if you want to
get an idea of the scope of the project.
Easier to add an ADA front-end, or even a COBOL front-end, than to develop all the HDL handling tools.
Kevin G. Rhoads
>
>IMHO -- No.
that merely "quite different".
Anonymous
> complex to implement,
Probably more complex than any common HLL in fact because of the requirement
of the compiler to maintain a project level (library) view of a program, all
its relationships etc. It's like configuration management and compilation
all rolled into one.
> The only working open source implementations had companies and finance
> behind the development.
In fact they had government money (your tax dollars if you're American)
behind them. Adacore (GNAT) was based on a publicly funded project at NYU
(New York University). The other big toolchain vendors are all almost
strictly federal sales. Lots of money (and talent) involved.
> Although originally designed to be safe the complexity of ada is such
> that it has been rejected for some safety concious tasks precisely
> because of that,
That is silly and untrue. SPARK is a safe subset of Ada with reduced
complexity. It's been around a fairly long time and even Ada itself is
demonstrably safer and more lucid than the best C++ or Java.
> mathematically proving a solution as safe was deemed to be an impossible
> task,
As it is in all complex programming projects
> After that implement ada in steps from that front end, Oberon and Ada
> are in some respects very different languages, however the basics are
> the same, they are both Pascal derivatives and the underlying concepts
> are very similar and in many instances the same.
Calling Ada a Pascal derivative is a dramatic oversimplication and also
imparts nothing useful to a person reading that statement.
Modula-2 is dead for all intents and purposes. I don't say it's a bad
language, it's interesting and solves some of the fundamental
not-ready-for-real-programming issues baked into Pascal. But it's not a
language to be resurrected. Ada is still in production, still has an active
standards committee, still has hundreds of millions of dollars behind it. I
don't think OpenWatcom can put together an Ada compiler though.
Olafur Gunnlaugsson
> Modula-2 is dead for all intents and purposes. I don't say it's a bad
> language, it's interesting and solves some of the fundamental
> not-ready-for-real-programming issues baked into Pascal. But it's not a
> language to be resurrected. Ada is still in production, still has an active
> standards committee, still has hundreds of millions of dollars behind it. I
> don't think OpenWatcom can put together an Ada compiler though.
>
M2's current status is neither here nor there, I was pointing out that a
basis for a start of a compiler front end exists and it is well worth
taking a look, the license is BSD and unless there are other reason for
rejecting it (which there may well be, and in fact are likely to exist)
nothing harmful can come out of it
Doing a quick search I could not find any other code that could be
appropriated, other front end implementations of ada or related
languages all have distribution restrictions that make them incompatible
with the watcom license
And this would not be a first, a number of other ada compilers
historically started out from Pascal, and is just an idea anyway
Olafur Gunnlaugsson
> On 2011-10-10 05:40, Olafur Gunnlaugsson wrote:
>
>> When it comes to ada however I would like to pipe in a bit, it is a bit
>> complex to implement, I personally know 2 such projects that never got
>> finished despite having finance and people behind it etc., and a number
>> of projects that did get finished were a bit "lacking" to say the least.
>
> I have an interest in Ada and, in fact, use it much more than either C
> or C++ these days. For fun I've started my own Ada implementation in
> Scala. See:
>
> https://www.assembla.com/code/augusta/subversion/nodes
> http://augusta-notes.blogspot.com/
Neat
>
> This project is in the very early stages; there is essentially nothing
> there right now. Due to other pressures on my time I don't expect to
> make any significant progress for a while but to give myself at least a
> little structure I have set a release date of December 31, 2020.
If some of my friends experience is to go by that is a bit optimistic ....
>> Although originally designed to be safe the complexity of ada is such
>> that it has been rejected for some safety concious tasks precisely
>> because of that, mathematically proving a solution as safe was deemed to
>> be an impossible task...
>
> The SPARK subset of Ada is used for safety critical systems in a number
> of contexts. It is possible to mathematically prove the correctness of
> programs using SPARK (for some suitable definition of "correctness"). I
> ought to know; I use SPARK daily in connection with a project I'm
> working on at Vermont Technical College.
Yes, but it is still more complex than it needs be for a safe system
>
> Full Ada is also used in a number of safety critical contexts, such as
> flight control systems on various aircraft, to name one example. In any
> case it is far easier to verify programs in Ada than in C or even C++,
> but that's not saying much as both C and C++ are highly unsafe.
yes, they sort of cheat as they use multiple computers, I think Airbus
has triplets for each decision for critical system, at the least 2 have
to agree before an action is taken
It's
> more interesting to compare Ada vs C with advanced tool support, or to
> compare Ada vs some other modern language designed for robust systems
> such as Eiffel. Comparing Ada directly with C is like kicking a man who
> is down.
It is also apples and oranges, C is a subset of a 60's system language
and for things like drivers it is if nothing else a great step forward
from assembly, but seeing mission critical or highly distributed systems
written in C rather than something like Erlang makes me cringe
Olafur Gunnlaugsson
>
> That is silly and untrue. SPARK is a safe subset of Ada with reduced
> complexity. It's been around a fairly long time and even Ada itself is
> demonstrably safer and more lucid than the best C++ or Java.
>
Er... but C and Java are not structured languages, so even Turbo Prolog,
Atari Logo, DOS batch files, Commodore 64 Comal and Apple Integer BASIC
are more safe than these 2, you could just as well compare Ada to
Javascript and PHP and state that it is inherently safer, meaningless
comparison.
SPARK is sill too big for safety as the sole factor, and SPARK was the
toolset that was rejected in favour of SM2 in the example I took,
funnily enough. The SPARK project started in the very early 80's and
took what, 10 - 15 years to be deemed robust enough to be used in a safe
environment (Program Validation Limited, the company that took over the
SPARK project from U. of Southampton was founded in 1983 expressly for
that purpose, despite what Wikipedia says the SPARK project pre-dates
Ada 83).
The SM2 was delivered in weeks
>> mathematically proving a solution as safe was deemed to be an impossible
>> task,
>
> As it is in all complex programming projects
>
There is a huge gap between the words impossible and difficult, given
that in at the least one instance this has happened impossible does not
apply across the board
> Calling Ada a Pascal derivative is a dramatic oversimplication and also
> imparts nothing useful to a person reading that statement.
Are the theatrics necessary ?
Ada is quite literally a Pascal derivative, the first experimental
compilers were derived from Pascal compilers it was not until later when
a proper definition of it had been hammered out that it was redone in
SETL (spelling?). I know people mention Algol 68 as the basis of Ada but
the semantics of ada are those of Pascal not of Algol, hence a
derivative in any meaning of the word just like Pascal is a derivative
of Algol, it is now radically different in some ways, the object system
and the massive Ada library is obviously missing and the language
continues to diverge slowly but the basic semantics and structure not
so, I thinks peoples experience of later versions of Turbo Pascal tends
to colour their view of the language a bit too much.
Remember that people used to port their pascal code to ada with minimal
changes in the 80's, that was usually UCSD Pascal, Dec or ISO at the
time obviously ...
A parser than handles Pascal/M2/Any other Wirth family language is very
close to being able to handle basic Ada language itself, that it lacks
the library etc. has nothing to do with with the front end itself. That
is the reason that I suggested it, nothing more, nothing less.
Marty Stanquist
case development prior to FPGA implementation on a Xilinx or Altera toolkit.
OW will be a better platform for behavioral simulation in the case where
embedded microcontrollers and sophisticated environment models are involved.
You would use OW to get all the hardware behavioral models, real-time
software routines, external environment models, and simulation test cases
designed, integrated, and simulating behaviorally. After all the
simulations are correct, you would transfer the HDL and simulation stimulus
files over to an FPGA vendor toolkit for compilation, targetting, and
layout. Once this is complete, you would transfer the gate level netlist and
sdf delay files back to OW, then run gate level simulations on both
platforms (OW and FPGA vendor) and compare the results. The objective will
be to keep OW as simple as possible, using it mainly as a system simulation
platform, not necessarily replacing FPGA vendor tools. I've found that most
of the work done in developing Verilog and VHDL was accomplished with just a
simple context-sensitive text editor, a logic simulator, and a waveform
viewer.
Marty
Marty Stanquist
scope to implementing the Verilog and VHDL compiler front ends and runtime
libraries, enhancing embedded microcontroller support, and adding a simple
waveform viewer. This should be do-able in a reasonable timeframe. Ada
support, while highly desirable, will need much more research.
Marty
Rugxulo
Unless you just really love Ada or really need some crucial
standardized features (tasks?), I don't see why it has to be Ada, per
se. And if your only goal is to bootstrap a VHDL front-end, you don't
need to write your own Ada for that, just use GNAT (or one of several
others). Ask yourself what features you need first, then worry about
what kind of syntax you want. (It's not so much that they're all the
same, they're not, but some of them explicitly glean features from
other languages. And of course some are better supported than others.
But this is probably all hypothetical anyways.)
Rugxulo
On Oct 10, 2:22 pm, Olafur Gunnlaugsson <oligunnla...@gmail.com>
wrote:
> ann 10/10/2011 16:30, skrifa i Anonymous:
>
> > Modula-2 is dead for all intents and purposes.
Normally that would sound like quite a stretch, but it's probably
"mostly" true. :-/ The amount of compilers, books, source code,
and users isn't nearly enough for it to be considered anywhere near
top tier (or truly active) anymore. For whatever odd reasons, it seems
to have been most popular from 1987-1991.
> > I don't say it's a bad
> > language, it's interesting and solves some of the fundamental
> > not-ready-for-real-programming issues baked into Pascal.
Right, it's a quite nice language (IMHO) and has a lot going for it.
But some people moved on to other languages, Wirth (Oberon) and
Odersky (Scala) included! Even some of the people who moved on to
other similar languages (Modula-3) have moved on to other other
languages (Cardelli -> C#, F#). Java and Python borrowed quite a bit
from M3.
Actually M3 is (I suppose) a cousin to Oberon and Object Pascal with
feature parity similar to C++ and Ada. But I suppose M2 is
"cleaner" (or at least easier) to implement. Even FreePascal can
target JVM now (and similarly various Oberon dialects target .NET). My
point is there is (intentionally) a lot of overlap there.
> > But it's not a language to be resurrected.
Well, depends on how dead you really think it is. If it's good, use
it, simple as that. If you want something else, that's fine too.
Nobody's stopping you from building such a compiler.
Two (very loosely speaking) "free" ISO M2 compilers exist (XDS, GM2),
and one more commercially for Mac (p1) also. XDS seems not updated
since 2005 (and by default non-commercial only??). But GM2 (GPL3) and
p1 (commercial) are still being updated very recently.
> Ada is still in production, still has an active
> > standards committee, still has hundreds of millions of dollars behind it. I
> > don't think OpenWatcom can put together an Ada compiler though.
Modula-2 has a standard (ISO 10514, 1996) and two official optional
extensions (1997, 1998). Apparently the big selling points are the
standardized library (albeit weird), COMPLEX, TRY..CATCH, etc.
> M2's current status is neither here nor there, I was pointing out that a
> basis for a start of a compiler front end exists and it is well worth
> taking a look, the license is BSD and unless there are other reason for
> rejecting it (which there may well be, and in fact are likely to exist)
> nothing harmful can come out of it
The sole maintainer for ACK these days has never even finalized the
6.0 release. Traditionally it used (his words) an "extremely arcane"
build process for old *nix machines. (Now 6.0 uses some weird embedded
Lua stuff, heh. Yes, I built it like once or twice for PuppyLinux. It
doesn't really support barely any OSes anymore, at least not 6.0, plus
5.6 is too old. The Linux support is a "dirty hack.") I don't even
think the compiler suite was updated past 1994 before he touched it
(mid 2000s). Just FYI, it only supports PIM3, no ISO anything, thus
you may or may not like that.
It's written in C, so "in theory" (famous last words) it could be
buildable by OW. And yes, BSD-licensed.
> Doing a quick search I could not find any other code that could be
> appropriated, other front end implementations of ada or related
> languages all have distribution restrictions that make them incompatible
> with the watcom license
>
> And this would not be a first, a number of other ada compilers
> historically started out from Pascal, and is just an idea anyway
(unverified but easy to check later, if anyone cares)
SmallAda was the Pascal-y subset written in Turbo Pascal. GWU NYU
Ada83 was in C. [Old] Augusta (very wimpy subset) was written in
unstructured BASIC and later ported to Turbo Pascal. And of course
GNAT uses the GCC backend but the frontend is written in itself. Heck,
you may have better luck with P2C (or similar).
Wilton Helm
a Xilinx FPGA in them, part of which is coded in Verilog. Verilog is
syntactically similar to C and VHDL is syntactically similar to Ada. Since
I'm writing in a C newsgroup (and not an Ada newsgroup) it is probably not
surprising that I prefer C to Ada in software, and that I prefer Verilog to
VHDL for hardware.
There are a number of tools out there to experiment with HDLs. But from my
position (down in the trenches) HDL tools are of little value (except maybe
in the classroom) unless they target hardware. I don't know how many
tutorials I've seen that spend most of their time talking about simulation
related directives and almost no time about how a construct actually maps to
a flip-flop. Not that simulation doesn't have a place, but if people
weren't designing hardware, HDLs wouldn't exist, and that point seems to be
lost on many people.
OK, so what's my point? As has been mentioned, the back end is completely
orthogonal to software compiling. If we had a few hundred programmers
anxiously waiting for somthing to do, maybe this would be a useful idea.
However, given that we are only slowly working towards a credible C++
implementation, I don't see a lot of people looking for new challenges that
are almost unrelated to OWs mission. It would take mostly an entirely
different group of people to understand the requirements and issues and be
able to contribute to a competitive implementation. If economics are any
indication, commercial HDL tools are about 10 times the cost of commercial
C/C++ compilers. Granted some of that is because there is a smaller
customer base.
At the end of the day, to be worth the effort to create it, it would have to
seamlessly integrate into the back-ends of Xilinx's ISE and similar products
from Actel, Altera, etc. Since ISE already has a reasonably credible front
end (at least for small to medium projects) that is freely downloadable from
their web site, it would have to have some pretty impressive specs to gain
much of a user base..
Wilton
Marty Stanquist
published BNF's, you could also parse them in C using tools such as Lex and
Yacc or using a more direct approach similar to that used in f77. GNAT is
definitely an option for compiling the VHDL front end. But like you are
suggesting, for now I'll focus on features and syntax, hopefully getting the
project specified in the next month. The initial effort will be to define
the Verilog and VHDL compiler front ends, the individual C interface
libraries, and a common runtime library.
Marty
"Rugxulo" wrote in message
news:c932b578-35b2-464a...@g25g2000yqh.googlegroups.com...
Marty Stanquist
heavy lift. I don't think we really want to try replacing them. The real
opportunity for Open Watcom is to offer enough HDL simulation capability to
enable full hardware, software, and environmental verification of embedded
designs containing microcontrollers, memories, and analog interfaces. In
particular, the proposed system would be highly useful for verifying designs
in which the microcontroller is to be included within the FPGA logic. All
this modeling will require compiling lots of code written in Verilog, VHDL,
C, C++, and Fortran. I anticipate using Open Watcom to get all the HDL code,
real-time software, environment models, and stimulus vectors simulating
together, then transferring the HDL code and stimulus vectors over to the
FPGA toolkit for targeting and gate level simulation. This is how I would
use the system.
Marty
"Wilton Helm" wrote in message news:j788qr$6ro$1...@www.openwatcom.org...
Rugxulo
On Oct 13, 10:13 pm, "Marty Stanquist" <martys...@att.net> wrote:
>
> This is true. Ada is just one approach. With Verilog and VHDL having
> published BNF's, you could also parse them in C using tools such as Lex and
> Yacc or using a more direct approach similar to that used in f77.
(To quote Peter in an earlier related message in this thread):
"As part of my Augusta project I will have an Ada parser. Could that
parser be used as a starting point for a VHDL parser? Maybe. However,
my
parser uses the ANTLR parser generator and is ultimately in Java.
These
tools are not part of the Open Watcom ecosystem so a VHDL compiler in
Open Watcom would probably need a different parser than the one I'm
building."
You could probably also use Coco/R (or one of its variants), which
isn't as exclusively tied to C/C++ as yacc/bison and lex/flex. It's
been ported to a variety of host languages and also has several
example grammars for various languages too.
Anonymous
> �ann 10/10/2011 16:30, skrifa�i Anonymous:
>
> >
> > That is silly and untrue. SPARK is a safe subset of Ada with reduced
> > complexity. It's been around a fairly long time and even Ada itself is
> > demonstrably safer and more lucid than the best C++ or Java.
> >
>
> Er... but C and Java are not structured languages,
That's debateable but anyway not relevant to a safety discussion. Safety has
to do with *type* safety and enforcement, pointer/memory management, runtime
bounds checking on all types, general error handling capabilities, etc. all
things Ada does much better than most other HLL. I said C++ btw and you
changed it to C. C is less safe than C++ or Java, obviously.
> so even Turbo Prolog, Atari Logo, DOS batch files, Commodore 64 Comal and
> Apple Integer BASIC are more safe than these 2, you could just as well
> compare Ada to Javascript and PHP and state that it is inherently safer,
> meaningless comparison.
The comparison I made is useful because C++ and Java are about the only
other languages used where safety is on the requirements list at all (of
course they fall very short) and considered more or less equivalent from a
functional standpoint (can accomplish similar things) with Ada. None of the
languages you listed are. The three I mentioned are compiled languages with
runtimes and have other important similarities. I don't understand your list.
> The SM2 was delivered in weeks
Yes, we agreed Ada is complicated. But Modula-2 isn't a replacement for Ada,
it's a replacement for Pascal and how fast something can be delivered isn't
a worthy goal for something of value. It's a goal if you want something
cheap. You have can have it cheap but it won't be fast or good.
> There is a huge gap between the words impossible and difficult, given
> that in at the least one instance this has happened impossible does not
> apply across the board
It applies in any meaningful context. One scenario does not a proof make.
> > Calling Ada a Pascal derivative is a dramatic oversimplication and also
> > imparts nothing useful to a person reading that statement.
>
> Are the theatrics necessary ?
What theatrics? I could rightfully call Pascal an ALGOL derived language.
There was nothing new at all in Pascal except the one-pass compilation
system and the emphasis on write once compile many times design. Pascal is
an academic exercise, it's not a language for production. It's not any kind
of a foundation language and misunderstanding it to believe it is is
harmful.
> Ada is quite literally a Pascal derivative, the first experimental
> compilers were derived from Pascal compilers
Citation please. What I read about the Ada language competition leads me to
believe all the compilers were custom written and the papers submitted also
seem to reflect that.
> it was not until later when a proper definition of it had been hammered
> out that it was redone in SETL (spelling?).
SETL was used for prototyping an *educational* version of Ada called
Ada/Ed. AFAIK it was never used in production and it was certainly not used
to write the GNAT (NYU) Ada even though GNAT was written at the same place
as Ada/Ed. And what does this have to do with our discussion? The only
commonality is that Pascal and Ada/Ed are both useless for real-world
problems for many reasons, including efficiency of generated code. They can
be considered proof of concept, not much more than that.
> Remember that people used to port their pascal code to ada with minimal
> changes in the 80's, that was usually UCSD Pascal, Dec or ISO at the
> time obviously ...
I can port Ada to PL/I and back more or less the same way except for a few
features. Pascal did relatively nothing, of course it's easy to port to any
common block structured language *from* Pascal to ALGOL68, PL/I, Modula-2.
That also doesn't mean much except as an academic exercise.
> A parser than handles Pascal/M2/Any other Wirth family language is very
> close to being able to handle basic Ada language itself, that it lacks
> the library etc. has nothing to do with with the front end itself. That
> is the reason that I suggested it, nothing more, nothing less.
I would like to hear from compiler writers who really know Ada because I
don't agree with your conclusion. I think you are oversimplifying things
because the basic syntax of Ada is not what makes Ada powerful. The
extensive type checking and tracking of program relationships and runtime
checks are what make Ada Ada.
Peter C. Chapin
> I would like to hear from compiler writers who really know Ada because I
> don't agree with your conclusion. I think you are oversimplifying things
> because the basic syntax of Ada is not what makes Ada powerful. The
> extensive type checking and tracking of program relationships and runtime
> checks are what make Ada Ada.
My experience building an Ada compiler is limited right now, but it
seems to me that the syntax of Ada is not particularly complex. Aside
from a few fairly well understood ambiguities, I believe parsing Ada to
be straightforward. I'll know better after I get my parser working. :)
This is to be contrasted with C++ which is nightmarish to parse. It is
an unfortunate aspect of C++ that so much effort must be expended to
parse it. That's effort that could have been used instead in improving
other aspects of the compiler. Also the complexities of parsing C++
inhibits tool support. Fortunately projects like clang are trying to
address this by provided a highly modular compiler that allows tools to
just call the parser like a library. Very cool stuff. Kudos to the clang
guys.
The complexity of Ada is definitely mostly in its semantics which are
very rich with many subtleties. In my Augusta project I intend to
approach the problem by first building a parser for the full language,
since I don't think that will be too scary (probably with some
restrictions related to symbol table handling). After that I will focus
on the SPARK subset of Ada. A compiler that can only compile SPARK would
still be useful to some and yet much easier to build. SPARK removes a
large number of features from the full language. Once that is done I'll
worry about adding on the additional features in some manner.
Peter
Marty Stanquist
Marty
"Rugxulo" wrote in message
Marty Stanquist
Marty
Rugxulo
On Oct 14, 2:52 pm, "Peter C. Chapin" <PCha...@vtc.vsc.edu> wrote:
> On 2011-10-14 14:48, Anonymous wrote:
>
> > I would like to hear from compiler writers who really know Ada because I
> > don't agree with your conclusion. I think you are oversimplifying things
> > because the basic syntax of Ada is not what makes Ada powerful. The
> > extensive type checking and tracking of program relationships and runtime
> > checks are what make Ada Ada.
>
> My experience building an Ada compiler is limited right now, but it
> seems to me that the syntax of Ada is not particularly complex. Aside
> from a few fairly well understood ambiguities, I believe parsing Ada to
> be straightforward. I'll know better after I get my parser working. :)
function() both using parentheses, as well as the whole complication
of generics (from what I've heard).
It's actually surprising some of the people who have gotten familiar
with Ada (e.g. Kenneth Almquist, who wrote a comparison to Modula-3,
and Jean-loup Gailley) considering they're sometimes known better for
other (C-based) things (Ash, Zlib).
http://web.archive.org/web/20060610031310/http://archive.dstc.edu.au/AU/staff/crawley/ada/m3-vs-ada.html
> This is to be contrasted with C++ which is nightmarish to parse. It is
> an unfortunate aspect of C++ that so much effort must be expended to
> parse it. That's effort that could have been used instead in improving
> other aspects of the compiler.
http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProposal.html
> Also the complexities of parsing C++
> inhibits tool support. Fortunately projects like clang are trying to
> address this by provided a highly modular compiler that allows tools to
> just call the parser like a library. Very cool stuff. Kudos to the clang
> guys.
C w/ GCC extensions, IIRC).
> The complexity of Ada is definitely mostly in its semantics which are
> very rich with many subtleties. In my Augusta project I intend to
> approach the problem by first building a parser for the full language,
> since I don't think that will be too scary (probably with some
> restrictions related to symbol table handling). After that I will focus
> on the SPARK subset of Ada. A compiler that can only compile SPARK would
> still be useful to some and yet much easier to build. SPARK removes a
> large number of features from the full language. Once that is done I'll
> worry about adding on the additional features in some manner.
target) and a few older Ada subsets. Maybe those will help? (Dunno.)
Rugxulo
On Oct 14, 1:48 pm, Anonymous <nob...@smtp.remailer.dyndns.org> wrote:
> > ann 10/10/2011 16:30, skrifa i Anonymous:
>
> > > That is silly and untrue. SPARK is a safe subset of Ada with reduced
> > > complexity. It's been around a fairly long time and even Ada itself is
> > > demonstrably safer and more lucid than the best C++ or Java.
>
> > Er... but C and Java are not structured languages,
>
> That's debateable but anyway not relevant to a safety discussion. Safety has
> to do with *type* safety and enforcement, pointer/memory management, runtime
> bounds checking on all types, general error handling capabilities, etc.
>
> > Apple Integer BASIC are more safe than these 2, you could just as well
> > compare Ada to Javascript and PHP and state that it is inherently safer,
> > meaningless comparison.
"software crisis"??), and Wirth was a big proponent of that. Most
common languages claim to be (mostly) structured. Wikipedia lists
three criteria: sequence (normal instructions), selection (if, case),
repetition (while, for). It's also often cited (Dijkstra??) for the
idea of "single exit point for each routine" and avoidance of "goto",
though some (most?) languages don't agree with (and ignore) that idea.
(Though Modula-2/Oberon and Java each omit any "goto" at all, unlike
Pascal.)
> The comparison I made is useful because C++ and Java are about the only
> other languages used where safety is on the requirements list at all (of
> course they fall very short) and considered more or less equivalent from a
> functional standpoint (can accomplish similar things) with Ada. None of the
> languages you listed are. The three I mentioned are compiled languages with
> runtimes and have other important similarities. I don't understand your list.
explicitly has safe and unsafe modules. It was used to write Taos and
SPIN OSes, esp. because of such type safety. Java and Modula-3 are
both garbage collected (while Ada and C++ usually aren't, if only by
choice and not purely technical reasons).
Actually, Modula-2 and Oberon were also both used to write OSes for
ETH Zurich machines (Lilith, Ceres), respectively. So they were indeed
for "real work". But no language can do everything, at least not
portably.
> > The SM2 was delivered in weeks
>
> Yes, we agreed Ada is complicated. But Modula-2 isn't a replacement for Ada,
> it's a replacement for Pascal and how fast something can be delivered isn't
> a worthy goal for something of value. It's a goal if you want something
> cheap. You have can have it cheap but it won't be fast or good.
some machines. I don't know of a language that doesn't have trouble
somewhere, and the more features you add, the harder it gets. So while
Ada is more feature-complete than others, it's moot if you can't
implement them safely or efficiently (or even at all). I'm not picking
on Ada specifically here, just lamenting the difficulty. I think Wirth
himself struggled with trying to take machine dependencies out of his
languages (and didn't always succeed doing so 100%). Even Modula-3
(and Perl, Python, Ruby) seem to be pretty *nix/POSIX-oriented in
their backends. Win32 is only usually supported because it's powerful
and popular enough (though API incompatible). Even things like pure
ANSI C (though extremely portable) are often (sadly) treated as too
weak for most projects. I admire Lua for its portability and build
simplicity.
> > > Calling Ada a Pascal derivative is a dramatic oversimplication and also
> > > imparts nothing useful to a person reading that statement.
>
> > Are the theatrics necessary ?
>
> What theatrics? I could rightfully call Pascal an ALGOL derived language.
> There was nothing new at all in Pascal except the one-pass compilation
> system and the emphasis on write once compile many times design. Pascal is
> an academic exercise, it's not a language for production. It's not any kind
> of a foundation language and misunderstanding it to believe it is is
> harmful.
(and is) indeed used professionally by many people. It's also been
extended several times, unofficially and officially. Don't forget that
there is no "one" Pascal, not even standards-wise, unless you reject
everything after Wirth's effort. ISO 7185 (classic Wirth Pascal) and
ISO 10206 (Extended Pascal) both exist, not to mention Turbo/Borland/
Delphi (and a bunch of much more obscure variants).
I don't know if it's fair to say Pascal didn't innovate at all. Sure,
it was inspired by ALGOL because Wirth was involved in the ALGOL
standards, even writing his own (simpler) variant ALGOL-W in lieu of
ALGOL 68.
Yes, Pascal was intended to be efficient (both compile-time and
runtime), structured, provably correct, good for algorithms, teaching
(engineers, physicists, mathematicians), writing compilers (often self-
hosted), abstract data types (ADTs), and as a means to write decent
programs on various machines (including the quirky CDC 6500). It's
very easy in hindsight to criticize him when that machine was quite a
beast (comparatively)!
And people have written OSes in Pascal variants too, but obviously the
"standard"(s) won't give you 100% (nor will ANSI C ... how do you read/
write a boot sector? inport/outport? rotate register?).
I don't want to get too defensive, I'm far from a pro, Pascal or
otherwise, just passing along some random trivia. It's fine if you
don't like it, that's life. You can't please everyone. But obviously
the point is that some Pascal variation is easier to implement and
probably better than nothing. (Even "the great" Michal Necasek once
supposedly "almost" wanted to write his own Pascal front-end for
OpenWatcom.)
> > Ada is quite literally a Pascal derivative, the first experimental
> > compilers were derived from Pascal compilers
>
> Citation please. What I read about the Ada language competition leads me to
> believe all the compilers were custom written and the papers submitted also
> seem to reflect that.
no surprise consider how generous Dr. Wirth has been teaching/sharing
compiler construction over the years. He was giving out sources to
Pascal_P, P2, P4, etc. to pretty much anybody who wanted them. By 1980
supposedly there were like 80 compilers in existence. (Even GCC
originated as a short-lived frontend to a Pascal derivative, Pastel.)
And yes, I've read the BWK 1981 paper, but it doesn't apply nowadays.
Arguably he was just upset that the (then-upcoming) standard didn't
include enough things. If he really hated it, why did he bother
porting his _Software Tools_? (Or the better question is why he never
updated to Modula-2 or Ada or ....) I guess C wasn't reliable enough
(non-standard).
> > it was not until later when a proper definition of it had been hammered
> > out that it was redone in SETL (spelling?).
>
> SETL was used for prototyping an *educational* version of Ada called
> Ada/Ed. AFAIK it was never used in production and it was certainly not used
> to write the GNAT (NYU) Ada even though GNAT was written at the same place
> as Ada/Ed.
that. If by "production" you mean air traffic control, then yes, I'd
probably guess you're right. I don't think it was meant to be an end-
all for every Ada project. (You have to start somewhere, no matter how
small.)
> And what does this have to do with our discussion? The only
> commonality is that Pascal and Ada/Ed are both useless for real-world
> problems for many reasons, including efficiency of generated code. They can
> be considered proof of concept, not much more than that.
Compaq/HP), compiler author, who actually says it's slightly easier
for the Pascal front-end to generate efficient code than other
languages (e.g. C). I blindly assume that's regarding aliasing of
pointers.
But of course efficiency depends on a lot of things (architecture,
compiler, algorithms), not "necessarily" the language itself.
> > Remember that people used to port their pascal code to ada with minimal
> > changes in the 80's, that was usually UCSD Pascal, Dec or ISO at the
> > time obviously ...
>
> I can port Ada to PL/I and back more or less the same way except for a few
> features. Pascal did relatively nothing, of course it's easy to port to any
> common block structured language *from* Pascal to ALGOL68, PL/I, Modula-2.
> That also doesn't mean much except as an academic exercise.
language includes everything.
I don't know PL/I (and I think you said you do, assuming you the same
"Anonymous", heh), but apparently it was a combined language trying to
unify COBOL, ALGOL, FORTRAN. (That reminds me, Pascal was also meant
as a structured replacement to old unstructured FORTRAN "back in the
day", obviously less so in newer standards [F77 ??]. I don't think
Wirth was happy with the pre-existing compilers for other languages:
too buggy, too slow.)
> > A parser than handles Pascal/M2/Any other Wirth family language is very
> > close to being able to handle basic Ada language itself, that it lacks
> > the library etc. has nothing to do with with the front end itself. That
> > is the reason that I suggested it, nothing more, nothing less.
>
> I would like to hear from compiler writers who really know Ada because I
> don't agree with your conclusion. I think you are oversimplifying things
> because the basic syntax of Ada is not what makes Ada powerful. The
> extensive type checking and tracking of program relationships and runtime
> checks are what make Ada Ada.
languages have different parsing needs: LL(1), LL(k), LALR, GLR, etc.
I know that Pascal supposedly didn't need a symbol table like C did.
The big complaints regarding original Pascal were that you couldn't
take arbitrary addresses of functions or variables, nor could you
easily (if at all) coerce variables to different types or
representations. Modula-2 fixed this somewhat, but it was still
misused. Those features were meant to be used minimally and safely,
and many languages (including Ada, Oberon, etc.) all try to get things
done without being as error-prone as C (though you can, and people do,
blame coders instead of the language, which is probably mostly
reasonable). Many people, Wirth included, don't feel you need to
sacrifice type safety for raw expressiveness and power. (Modula-2 and
Oberon are meant to be type safe across modules/packages, unlike C,
which I think just lets the linker flag any problems and has to
continually re-parse the headers over and over again.)
Also, runtime checks are fine but sometimes expensive, esp. without
hardware support in some cases. So a lot of people shun that, too. (It
seems there is little that everybody agrees upon.) Luckily even
original Pascal (and derivatives) usually let you disable at compile-
time, and even some Ada compilers can optimize away the runtime checks
if they aren't needed. Obviously Ada was meant to be statically
checked at compile time if at all possible.
Also, one of the complaints with C is that something strange will
compile without warnings but not work properly. This is why Lint (and
max warnings enabled) seems to be suggested a lot. This is also why
prototypes for functions were later added.
And yes, the "big" change from original Pascal to Ada or Modula-2 was
the modularization of everything (.def, .mod or .ads, .adb). I even
almost want to call Oberon a close relative of Modula-2 (and it is),
but it's got enough (incompatible) differences to indeed be considered
an entirely different ("improved"??) language.
(Sorry if this was too long or sorta off-topic, just rambling in a
weak attempt to be informative, corrections welcome ....)
Peter C. Chapin
> Ada is probably more difficult (or even impossible?) to implement on
> some machines. I don't know of a language that doesn't have trouble
> somewhere, and the more features you add, the harder it gets. So while
> Ada is more feature-complete than others, it's moot if you can't
> implement them safely or efficiently (or even at all).
compiler that compiles to C so one could argue that Ada can be
implemented on any system that supports C. That said, the trick is in
the run time system, but I think that's mostly a matter of size than
impossible complexity.
There are various optional annexes to the Ada standard some of which
require some pretty low level stuff. I'm thinking of the Real Time
Systems Annex particularly. I could see that being unimplementable
(fully) on top of a non-real time OS. I'm not sure.
> I'm not up on my parsers, so I don't know. I have heard that different
> languages have different parsing needs: LL(1), LL(k), LALR, GLR, etc.
> I know that Pascal supposedly didn't need a symbol table like C did.
> Also, runtime checks are fine but sometimes expensive, esp. without
> hardware support in some cases. So a lot of people shun that, too. (It
> seems there is little that everybody agrees upon.) Luckily even
> original Pascal (and derivatives) usually let you disable at compile-
> time, and even some Ada compilers can optimize away the runtime checks
> if they aren't needed. Obviously Ada was meant to be statically
> checked at compile time if at all possible.
checks. Of course that is considered dangerous. The Ada standard has a
pragma Suppress that can be used to remove certain checks in certain
scopes (compilers can ignore it). The compiler is allowed to optimize
checks away if it can prove that they'll never fail.
In my work with SPARK we intended to completely remove all run time
checks from the executable. SPARK will allow us to prove statically that
the checks will never fail in every case (even cases where the compiler
can't figure it out) so we don't need those checks bulking up the program.
Peter
Peter C. Chapin
> I don't know exactly. Seems like something to do with array() and
> function() both using parentheses, as well as the whole complication
> of generics (from what I've heard).
calls. I believe many of these issues can be resolved with a symbol
table. I'm not familiar right now with the parsing issues introduced by
generics. Off hand it doesn't seem like generics would be a big deal. I
guess I'll find out. :)
> Ever heard of SPECS? Though I don't know if it was ever implemented.
>
> http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProposal.html
different language to me.
> I previously mentioned Coco/R (with Ada host port and micro-Ada
> target) and a few older Ada subsets. Maybe those will help? (Dunno.)
used it before in a different project and I like it pretty well. It
remains to be seen how well it will work for me here.
Peter
Anonymous
>
> > Ada is probably more difficult (or even impossible?) to implement on
> > some machines. I don't know of a language that doesn't have trouble
> > somewhere, and the more features you add, the harder it gets. So while
> > Ada is more feature-complete than others, it's moot if you can't
> > implement them safely or efficiently (or even at all).
the main language and zero or more annexes (libraries, for lack of a better
one-word definition). I don't know any reason why Ada shouldn't be able to
be implemented on any standard microprocessor, indeed it was designed to run
in the embedded space from the very beginning as opposed to most languages
that were designed, and then had compilers written to target embedded
environments.
Peter Chapin wrote
> There are various optional annexes to the Ada standard some of which
> require some pretty low level stuff. I'm thinking of the Real Time
> Systems Annex particularly. I could see that being unimplementable
> (fully) on top of a non-real time OS. I'm not sure.
appropriate on many targets as well, consider the data processing annex. If
you're not doing decimal math (money) you don't need this annex.
Rugxulo
On Oct 15, 12:58 pm, "Peter C. Chapin" <PCha...@vtc.vsc.edu> wrote:
> On 2011-10-15 12:29, Rugxulo wrote:
>
> > Ada is probably more difficult (or even impossible?) to implement on
> > some machines. I don't know of a language that doesn't have trouble
> > somewhere, and the more features you add, the harder it gets. So while
> > Ada is more feature-complete than others, it's moot if you can't
> > implement them safely or efficiently (or even at all).
>
> I suspect Ada is implementable on most things.
(x86, PPC, IA64), but there are other weirder cpus and OSes out there.
(The fact that most software companies only seem to support Linux and
Windows may be more of a commercial bent than pure technical
limitations. But it's a pet peeve of mine, I don't consider limited
POSIX + Win32 support truly universally portable.)
> There exists an Ada 95
> compiler that compiles to C so one could argue that Ada can be
> implemented on any system that supports C. That said, the trick is in
> the run time system, but I think that's mostly a matter of size than
> impossible complexity.
sometimes. The most simplistic way to do it seems to be with setjmp/
longjmp, but allegedly some C systems are buggy (as those functions
are claimed to be difficult to implement). I'm just saying, it seems
there is no easy answer to real portability. Nevertheless, C++ is
widely implemented (e.g. G++), so if it can be done there, it can be
done elsewhere. (FYI, GNU Modula-2 uses C++ style [compatible]
exceptions and GNU Pth for coroutines.)
(combining messages here for simplicity)
On 2011-10-15 11:38, Rugxulo wrote:
>> I don't know exactly. Seems like something to do with array() and
>> function() both using parentheses, as well as the whole complication
>> of generics (from what I've heard).
>
> Another example is the ambiguity between type conversions and function
> calls. I believe many of these issues can be resolved with a symbol
> table. I'm not familiar right now with the parsing issues introduced by
> generics. Off hand it doesn't seem like generics would be a big deal. I
> guess I'll find out. :)
most complexity and difficulty to Ada.
>> Ever heard of SPECS? Though I don't know if it was ever implemented.
>>
>> http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProposal.html
>
> I haven't heard of it before, but it looks like an argument to use a
> different language to me.
apparently Wirth (and Ada) got it right somehow. I don't know C++, so
I can't fairly say, but while I (so far) feel it's too complex
syntactically, C++ is still ridiculously popular, so apparently it
doesn't bother most people.
(BTW, minor pet peeve, SPECS website seems down today, doh, and the
Wikipedia page was deleted for being "not notable", esp. because no
actual implementation exists. Sigh. So much for good ideas.)
http://web.archive.org/web/20110629062323/http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProposal.html
"We describe an alternative syntactic binding for C++. This new
binding includes a completely redesigned declaration/definition syntax
for types, functions and objects, a simplified template syntax, and
changes to several problematic operators and control structures. The
resulting syntax is LALR(1) parsable and provides better consistency
in the specification of similar constructs, better syntactic
differentiation of dissimilar constructs, and greater overall
readability of code."
>> I previously mentioned Coco/R (with Ada host port and micro-Ada
>> target) and a few older Ada subsets. Maybe those will help? (Dunno.)
>
> I'm using ANTLR as the parser generator in my Ada compiler project. I've
> used it before in a different project and I like it pretty well. It
> remains to be seen how well it will work for me here.
isn't as big a deal. I think (??) one of the popular JVMs is written
in C++ anyways (which OW obviously supports), and similarly Bochs. So
"in theory" OW could still indirectly bootstrap it (famous last
words). ;-)
Fritz Wuehler
> On 2011-10-14 14:48, Anonymous wrote:
>
> > I would like to hear from compiler writers who really know Ada because I
> > don't agree with your conclusion. I think you are oversimplifying things
> > because the basic syntax of Ada is not what makes Ada powerful. The
> > extensive type checking and tracking of program relationships and runtime
> > checks are what make Ada Ada.
>
> My experience building an Ada compiler is limited right now, but it
> seems to me that the syntax of Ada is not particularly complex. Aside
> from a few fairly well understood ambiguities, I believe parsing Ada to
> be straightforward. I'll know better after I get my parser working. :)
relatively free of constructs that could mean more than one thing. As you
know some of the guys who have written successful Ada compilers hang out on
comp.lang.ada. I'm sure they would be interested in your work and probably
have a lot of helpful comments (I haven't seen you post anything on your
project on that newsgroup, maybe I missed it).
> This is to be contrasted with C++ which is nightmarish to parse. It is
> an unfortunate aspect of C++ that so much effort must be expended to
> parse it.
overloading of operator symbols and C++ only made things worse. It (C)
seemed so poorly thought out from a syntactic level although obviously it
was an ingenious thing from a semantic point of view.
> That's effort that could have been used instead in improving other aspects
> of the compiler. Also the complexities of parsing C++ inhibits tool
> support.
ugly. What you said about tool support doesn't surprise me.
> The complexity of Ada is definitely mostly in its semantics which are
> very rich with many subtleties. In my Augusta project I intend to
> approach the problem by first building a parser for the full language,
> since I don't think that will be too scary (probably with some
> restrictions related to symbol table handling). After that I will focus
> on the SPARK subset of Ada. A compiler that can only compile SPARK would
> still be useful to some and yet much easier to build. SPARK removes a
> large number of features from the full language. Once that is done I'll
> worry about adding on the additional features in some manner.
class files or is it written in Java with some other target?
Are you writing it in pure Java or Scala, I have to go back and read your
other post...
E. S. Fabian
distributed for comments (IIRC through the ACM Programming Languages group's
magazine), I talked to the head of the design committee asking why using the
same syntax for array element selection and for function argument
specification. The answer was: because a function may be implemented as an
array! Obviously this is feasible only when the function has a finite
domain, for example, trigonometric functions of those planar angles that are
integer multiples of a fixed, discrete resolution - a concept very much
commensurate with analog to digital conversion.
I thought this an interesting enough tidbit to add even this late.
BTW, a software department manager at a firm which at the time was heavily
involved in developing real-time mission critical software for DoD told me
that it took his experienced programmers several (more than six) months to
become proficient in Ada, but once there, they became more productive than
in other, less structured languages.
--
Steve
Peter C. Chapin
> I think this was part of the design. Ada, to be safe and readable has to be
> relatively free of constructs that could mean more than one thing. As you
> know some of the guys who have written successful Ada compilers hang out on
> comp.lang.ada. I'm sure they would be interested in your work and probably
> have a lot of helpful comments (I haven't seen you post anything on your
> project on that newsgroup, maybe I missed it).
the moment there is almost nothing to my project except the germ of an
idea. :) What's more I probably won't have time to do much with it for
several more months.
It's true that there are many people on that group who could be very
helpful. When the time comes I will definitely post an announcement
there of some sort.
> That sounds like a really interesting project. Did you say it produces Java
> class files or is it written in Java with some other target?
might seem like a strange choice to use Scala. I blogged about that
choice here
http://augusta-notes.blogspot.com/2010/12/why-scala.html
Here is where I talk about my choice of LLVM
http://augusta-notes.blogspot.com/2011/02/back-end-technologies.html
Peter
P.S. If you are curious about what I *am* doing with my time, my
dissertation project is a Scala compiler plug-in that will extend the
Scala language to create a novel type safe staged programming
environment for embedded systems developers using the nesC programming
language.
https://www.assembla.com/code/scalaness/subversion/nodes
Peter C. Chapin
> Back when the proposed syntax and semantics of Ada were generally
> distributed for comments (IIRC through the ACM Programming Languages group's
> magazine), I talked to the head of the design committee asking why using the
> same syntax for array element selection and for function argument
> specification. The answer was: because a function may be implemented as an
> array!
appropriate if the array is very large and one needs to save memory.
Instead of storing the array just compute the elements on demand. It's a
classic case of space/time trade-off. Thus whether something is a
function or an array is an implementation detail and that should not be
exposed in the syntax.
That's the idea, anyway.
Peter
Nomen Nescio
Rugxulo
(tried sending this reply last night, didn't work, luckily I saved
just in case)
Is it possible that [ ] square brackets are harder to type for other
language keyboards? (I think I remember one German-speaking guy saying
such. Or maybe that was backslash. Nope, I was right, Japheth said
(22.2.2008 on BTTR): "they're [bracket-heavy FASM syntax] evil
because
they force me, the innocent user, to use square brackets for accessing
variables. And the '[' and ']' are very hard to type in on German
keyboards")
C89 trigraph: ??( ??)
C94 digraph: <: :>
ISO 7185 Pascal: (. .)
ISO 10514 Modula-2: (! !)
So clearly there exist optional replacements in some common languages.
(The obvious question is why can't they all agree? Heh.)
Ada has replacements for a few things itself but not needed for this
one,
obviously.
Uwe Schmelich
> (naive question as American user who pretty much only uses ASCII)
>
> Is it possible that [ ] square brackets are harder to type for other
> language keyboards? (I think I remember one German-speaking guy saying
> such. Or maybe that was backslash.
difference for a programmer:
<http://en.wikipedia.org/wiki/Keyboard_layout
#Germany_and_Austria_.28but_not_Switzerland.29>
Backslash is a bit easier because you can get it with the right hand using
your thumb without much stretching.
I myself sometimes use the Alt+keycode sequences to type some of this
symbols. This may be faster on occasion (if your hand is near the num pad
anyway).
Uwe
Peter C. Chapin
> Is it possible that [ ] square brackets are harder to type for other
> language keyboards?
that's all your keyboard can provide you have a problem. C's trigraphs
came into existence to deal with that limitation. I don't know if anyone
is still using such limited keyboards, though.
For what's it worth Scala also uses '(' and ')' to access arrays. This
is because it regards array access as an invocation of a special method
named 'apply.' Thus in Scala array access and method invocation are, in
fact, the same. (As an optimization the compiler translates array access
operations into what you would expect at the JVM bytecode level).
Peter
E. S. Fabian
|
|| Is it possible that [ ] square brackets are harder to type for other
|| language keyboards?
|
| Yes, in fact the '[' and ']' characters are not part of ISO646 so if
| that's all your keyboard can provide you have a problem. C's trigraphs
| came into existence to deal with that limitation. I don't know if
| anyone is still using such limited keyboards, though.
for array indexing influenced both by commonality with function argument
specification (see notes earlier in this thread), and its use for both
purposes in all HLL-s used by the US DOD at the time in its real time
software.
--
Sorry, Peter, wrong keystroke sent the above to you instead of the NG.
Steve
Olafur Gunnlaugsson
>
> On Oct 10, 2:22 pm, Olafur Gunnlaugsson<oligunnla...@gmail.com>
> wrote:
>> ann 10/10/2011 16:30, skrifa i Anonymous:
>>
>>> Modula-2 is dead for all intents and purposes.
>
> Normally that would sound like quite a stretch, but it's probably
> "mostly" true. :-/ The amount of compilers, books, source code,
> and users isn't nearly enough for it to be considered anywhere near
> top tier (or truly active) anymore. For whatever odd reasons, it seems
> to have been most popular from 1987-1991.
languishing and later disappearing for reasons that had nothing to do
with the language or its popularity, the alternatives, on the PC at the
least, were expensive and slow, the other hotbed of M2 programming was
DEC where morphed it into M2* and later into M3 and when Compaq took
them over the lang division was closed down mostly.
The guy who wrote the Topspeed compiler went to work for Microsoft and
is the gent behind C#, some of the "new ideas" in C# are strangely
Oberon like.....
Olafur Gunnlaugsson
> Java and Python both borrowed quite a bit from Modula-3, which
> explicitly has safe and unsafe modules. It was used to write Taos and
> SPIN OSes, esp. because of such type safety. Java and Modula-3 are
> both garbage collected (while Ada and C++ usually aren't, if only by
> choice and not purely technical reasons).
assume you are talking about and another that was quite popular for a
time that was written in Transputer and 68000 assembly and later renamed
Intent
>
> Actually, Modula-2 and Oberon were also both used to write OSes for
> ETH Zurich machines (Lilith, Ceres), respectively. So they were indeed
> for "real work". But no language can do everything, at least not
> portably.
for OS writing as well