I'd rather switch than fight!
in [FPGA]
|
From: Andy on 15 Apr 2010 15:23 The benefits of a "strongly typed" language, with bounds checks, etc. are somewhat different between the first time you write/use the code, and the Nth time reuse and revise it. Strong typeing and bounds checking let you know quickly the possibly hidden side effects of making changes in the code, especially when it may have been a few days/weeks/months since the last time you worked with it. A long time ago there was a famous contest for designing a simple circuit in verilog vs. vhdl to see which language was better. The requirements were provided on paper, and the contestents were given an hour or two (don't remember how long, but it was certainly not even a day), and whoever got the fastest and the smallest (two winners) correct synthesized circuit, their chosen language won. Verilog won both, and I don't think vhdl even finished. IMHO, they missed the point. Any design that can be completed in a couple of hours will necessarily favor the language with the least overhead. Unfortunately, two-hour-solvable designs are not representative of real life designs, and neither was the contest's declared winner. If you just want to hack out the code and get it working by yourself for the day, a weakly typed language may be the better choice for you. If you need to be able to reuse/revise/update/extend the design over time, more strongly typed languages are preferred. Andy
From: David Brown on 15 Apr 2010 16:12 On 15/04/2010 21:23, Andy wrote: > The benefits of a "strongly typed" language, with bounds checks, etc. This is perhaps a nit-pick, but bounds checks are not directly related to type strength. Bound checks are either run-time (and therefore have a cost), or compile-time (or both). For compile time, this mainly means that the compiler must see the full declaration of the array or other type when you are using it - modern gcc will do pretty good compile-time bounds checking if it has enough information, even with weakly-typed C. > are somewhat different between the first time you write/use the code, > and the Nth time reuse and revise it. Strong typeing and bounds > checking let you know quickly the possibly hidden side effects of > making changes in the code, especially when it may have been a few > days/weeks/months since the last time you worked with it. > Agreed, although this applies to a lot of good programming techniques (you can write strongly-typed code even if the language doesn't enforce it, and typically the compiler's warnings will give you more help than the language standards). It's faster to write code full of functions "test" and "foo" than to think of meaningful names, but it makes a big difference when you go back to the code latter. > A long time ago there was a famous contest for designing a simple > circuit in verilog vs. vhdl to see which language was better. The > requirements were provided on paper, and the contestents were given an > hour or two (don't remember how long, but it was certainly not even a > day), and whoever got the fastest and the smallest (two winners) > correct synthesized circuit, their chosen language won. Verilog won > both, and I don't think vhdl even finished. > > IMHO, they missed the point. Any design that can be completed in a > couple of hours will necessarily favor the language with the least > overhead. Unfortunately, two-hour-solvable designs are not > representative of real life designs, and neither was the contest's > declared winner. > > If you just want to hack out the code and get it working by yourself > for the day, a weakly typed language may be the better choice for you. > If you need to be able to reuse/revise/update/extend the design over > time, more strongly typed languages are preferred. > > Andy Another famous contest involved a C and Ada comparison. It took the Ada more than twice as long as the C team to write their code, but it took the C team more than ten times as long to debug their code.
From: David Brown on 15 Apr 2010 16:19 On 15/04/2010 15:03, Brian Drummond wrote: > On Thu, 15 Apr 2010 10:32:43 +0200, David Brown > <david(a)westcontrol.removethisbit.com> wrote: > >> On 15/04/2010 04:07, glen herrmannsfeldt wrote: >>> In comp.arch.fpga rickman<gnuarm(a)gmail.com> wrote: >>> (snip) >>> >>>> People say that strong typing catches bugs, but I've never seen any >>>> real proof of that. There are all sorts of anecdotal evidence, but >>>> nothing concrete. Sure, wearing a seat belt helps to save lives, but >>>> at what point do we draw the line? Should we have four point >>>> harnesses, helmets, fireproof suits...? > >> The main thing is to write your code clearly, and to take advantage of >> whatever typing mechanisms your tool supports - even if it doesn't check >> them (for example, use typedefs and enums in C rather than "int", even >> though the compiler treats them the same). You can write good code in >> any language, and you certainly can write bad code in any language. But >> it is easier to write good code if the language and tools make support it. > > Then (using enums as a simple example), strong typing can either catch > or eliminate errors that may not immediately be considered as type > errors. > Yes - it's one of the advantages of C++ over C (C++ has plenty of advantages and plenty of disadvantages) - type checking, including enums, is much stronger. And with a bit of messing around with you can make types that are effectively enums but even stronger typed. I've seen some code to use C++ classes to encapsulate rules about lock orders for multi-threaded code (such as "you must not take lock A unless you first have lock B, and you must release them in reverse order"). The result was that violations of these rules ended up as type errors and were therefore caught at compile time. It's often possible to add features to the language in this way - some ugly macros will give you zero-cost static asserts in C, for example. > Loop count errors or indexing off the end of an array, for example, are > usually type errors, since they use the range of a discrete subtype. In > C you have to build something complex and error prone, simply to > replicate "for i in my_enum'range loop ..." And remember to maintain it > whenever you add a value to the enum... > typedef enum { red, blue, green, noOfColours } colours; for (int i = 0; i < noOfColours; i++) { ... } But it would be *so* much nicer if it were part of the language as it is in Ada or Pascal. >> >> Any checking mechanism has a risk of false positives and false negatives >> - the compiler doesn't know everything the programmer knows. But you >> work with the tool to give the compiler as much knowledge as you can, >> and let it help check that as much as /it/ can. >> > Agreed > > - Brian
From: Patrick Maupin on 15 Apr 2010 17:21 On Apr 15, 3:12 pm, David Brown <da...(a)westcontrol.removethisbit.com> wrote: > Another famous contest involved a C and Ada comparison. It took the Ada > more than twice as long as the C team to write their code, but it took > the C team more than ten times as long to debug their code. Well, this isn't at all the same then. The Verilog teams got working designs, and the VHDL teams didn't.
From: Patrick Maupin on 15 Apr 2010 17:27
On Apr 15, 2:23 pm, Andy <jonesa...(a)comcast.net> wrote: > The benefits of a "strongly typed" language, with bounds checks, etc. > are somewhat different between the first time you write/use the code, > and the Nth time reuse and revise it. Strong typeing and bounds > checking let you know quickly the possibly hidden side effects of > making changes in the code, especially when it may have been a few > days/weeks/months since the last time you worked with it. For this usage, a good testbench will catch more bugs and make strong type and bounds checking redundant. > > A long time ago there was a famous contest for designing a simple > circuit in verilog vs. vhdl to see which language was better. The > requirements were provided on paper, and the contestents were given an > hour or two (don't remember how long, but it was certainly not even a > day), and whoever got the fastest and the smallest (two winners) > correct synthesized circuit, their chosen language won. Verilog won > both, and I don't think vhdl even finished. Contest details here: http://www.see.ed.ac.uk/~gerard/Teach/Verilog/manual/Example/lrgeEx2/cooley..html > IMHO, they missed the point. Any design that can be completed in a > couple of hours will necessarily favor the language with the least > overhead. Unfortunately, two-hour-solvable designs are not > representative of real life designs, and neither was the contest's > declared winner. Well, I think the takeaway is a lot more nuanced than that, but whatever. Believe what you will. > If you just want to hack out the code and get it working by yourself > for the day, a weakly typed language may be the better choice for you. > If you need to be able to reuse/revise/update/extend the design over > time, more strongly typed languages are preferred. Again, IMHO, a really good testbench will more than make up for any perceived weaknesses in Verilog in this area. But you are free to continue to believe that the language is really helping you. Regards, Pat |