Any decent compiler or operating system will provide varying and
definable levels of checking.
What !. There is nothing unstable about 'C' (unless
you are using version 1.0 of the compiler) - it is the way it is used
and how well it is tested that counts. If you insist on using pointers
that don't point to anything, what do you expect. On a decent machine
with memory protection and privileges (like a VAX/Alpha) you should only
be able to crash your own process, never someone else's.
C is after all a high level assembler (anyone used Plan ??), and while
there may be better languages for writing operating systems , the
closer you get to the hardware the more useful it is. For bit-twiddling
it is perfect. I wrote the software for an analogue-addessable fire
alarm over 10 years ago. Main board had a trusty Z80 with 32K rAM and
64K bank switched EPROM (Z80 =cheap to buy in quantity and available in
CMOS, which is what you need for extended power fail sits.).
Loop controllers - 8051 with 128 *bytes* of RAM but as much EPROM as you
need, written in assembler and debugged with a 'scope.
Had to do it for a fixed price and the hardware didn't exist at the
time, and hardware guy had been rescued from redundancy at the age of 60
and had never done a digital board in his life. Interesting time - I had
no idea how much information could be obtained just using humble 2
channel 'scope, and not even storage one.
Oh, and I used C because Hitech (Oz company) did a cheap compiler for
the Z80 and provided you avoided bit manipulation on stack items it
generated tolerable code. Also meant I could use an intelligent EPROM
emulator to debug and single step in machine code.
 (DEC->Compaq-> Now Hewlett Packard ACMS still has modules written
in Bliss32. In fact I think it still their favourite language.
Personally I still think VAX FORTRAN 77 version 3 running VMS V3 was
the best combination, even for 'commercial' work since it had reasonable
character string handling - and if you used a separate database handler
you didn't need to use the languages rudimentary file handling.
PS the London Teching hosp. where I used the latter used to use an
Elliot 803 in the sixties - apparently it used mag tapes with sprocket
holes (so I was told).
Notice I used quotes in my original description :)
But that's the point (pun not intended). C allows you to do such a
thing, and the program will compile. Perhaps modern day C compilers
are more robust than what I was used to (I last used C in earnest
about 5 years ago), but my experience was that the C compiler did not
automatically produce code that did runtime checking. Whereas pascal
(etc) from the same vintage did.
BTW, of all the languages of which I am familiar I think C is/was my
favourite - it was lean and mean. I never liked pascal that much,
never did figure how anyone could like having to write "begin" and
"end" in program constructs (much easier to use curly brackets - less
typing). Fortran is model 'T' Ford vintage. VB is bloatware. And C++
was overloaded (pun intended) with features - very useful most of
them, but my eyes glazed over a bit with some of the buzzwords like
polymorphism, overloading, etc. Nothing wrong with C++, just that it
wasn't for me really.
Sending email to my published email address isn't
guaranteed to reach me.
C was writen by engineers, as a way if writing assembler faster.
Thats why its good for operating systems.
Hwver you do need a *little* assembler here and there.
I have written an operating system in C and assembler.
Kernigan and Rickie to be precise. They wrote the UNIX operating system
with it (UNIX was a pun on Multix a Honeywell OS). The centre kernel of
most UNIX versions is in machine code.
Depends on the compiler. A compiler only converts ASCII text to whatever.
A written program is only a document, just like a letter.
Do you mean UNIX kernel? Add your bits and re-compile.
For applications C is not the thing as it can be slow to produce programs.
A boss would be better with a 4 GL as it is faster and a slight learning
C is very powerful.
Checked by AVG anti-virus system (http://www.grisoft.com ).
Version: 6.0.561 / Virus Database: 353 - Release Date: 13/01/2004
That must be some new meaning of the word "precise" with which I was not
Kernighan and Ritchie must be two of the most famous names in computing.
You spell them both wrong and call it precise. Get back under your stone
and stop digging yourself into a deep hole again.
Just a small point. If you don't spell correctly, you will run into
trouble with C especially. If you don't punctuate correctly then the
results can be insidiously wrong and the compiler may not report it.
Yes and no. C was devloped from B, which was developed from BCPL.
kernighan and Ritchie simply wrote tghe official book, there wer others
involved in its design and evolution.
Yes and no.
You can. of course write 'inline assembler' in 'C' in most complers.
However it is not 'C'
C nbeing a stack based language, and having very little cobncetp of
registers - since the PDP CPU doesn't have many - does not map well or
make efficient use of registers.
Neither has it any concept of using IO space within the language, nor is
it very effeicient in all cases at doing bitmap operations.
To talk to the hardware usinc C alone is not possible. You have to have
at some level at least an assembler coded subroutine to do e.g. an IO
call, and other generic bit twiddling is usuially faster and easier to
implement in assembler, as are interrupt service routines.
It is of couse he fact tghat RISC chops are now being produced that
enavle almost pure C to be used to drive them - the are ooptimised for
teh way it does things. However Intel type architectires do NOT map well
into C and its a tribute to teh complier writers that we get teh
performance we do.
No, I mean a dedicated operating system for an 8088 microprocessor board.
I have in fact written the equivalent of what a home computer running
FORTH would have run in the early 80's. From scratch.
Horses for courese. Most higher level languages are woefully inefficient.
The problem with C is never speed, it is that it gets very big and hard
to debug on higher level stuff. It is the actual problems of miantaining
control over a huge project written in C that eventually make 4GL type
lkanguase -0 inefficient tho they are speed wise - at least manageable
in terms of software engineering.
Its as powerful as teh processor and machine it runs on.
Forth is smaller, but slower. In many respects its smaller than
assembler in terms of the program sizs. Its a bitch to write tho :-)
Stuff like PDL or BASIC is easy to cobble up stuff in, but woefully
slow. AND big.
Well it was 3ns a meter by the time I got into a proper electronics lab.
We even took a 100meter reel of cable, and shoved a pulse generator on
it to check
The reflection did take about 600ns to come all teh way back..
I am familiar with the basics of COFDM as well as the rival U.S.
system and have read the papers by Stott and others.
While COFDM should give good multipath performance, the code rate and
the guard intervals mean a compromise between the data rate and signal
robustness. I understand that there are various issues around the UK
system because of the limitations imposed by the current transmission
arrangements, but I haven't looked at that in depth.
In practice I have seen cases where the bit error rate is noticably
worse when cabling is poor or the antenna is not aligned correctly and
there is visual evidence of multipath reception on analogue.
I suspect, therefore, that as Stott admits in at least one of his
papers, while one can model some aspects of COFDM mathematically, some
issues can only be determined experimentally. It would appear that
the practicality may not be quite what the theory predicts.
DAB suffers in practice from limitations arising from the broadcasters
trying to squeeze more into the spectrum than will give the best
results. I haven't looked at the detail, but it would appear that
DVB-T has some issues as well.
To email, substitute .nospam with .gl
OK, sorry, but that wasn't clear from what you said.
It should and does give good multipath performance, up to (a little over)
the guard interval. As we're not using SFNs for TV the guard interval
fraction has been set to the lowest DVB option (1/32) to minimise the loss
ISTM that you're thinking more here of the choice of modulation
constellation and code rate. In 1998 DTT launched with 64-QAM modulation &
2/3 code rate, giving about 24Mb/s net data rate. Following the demise of
ITV Digital the BBC and Crown Castle decided to opt for 16-QAM to increase
robustness, but to reduce the code rate to 3/4 to claw back some of the lost
capacity. This combination gives about a 4 dB advantage in a gaussian
channel. So we now have a hybrid situation with the BBC & CCI running
16-QAM 3/4 (~18Mb/s) but with the D3&4 mux (ITV, C4, etc.) and SDN (C5, S4C,
etc.) still running 64-QAM 3/4.
The higher BER there might just be due to the signal being weaker, of
course, or to long-delayed echoes.
I think most aspects of it are now pretty well understood and measurements
agree well with theory. The performance of different receivers in the
presence of long-delayed echoes does vary though, and depends (IIRC)
somewhat on the Viterbi implementation. Unless you can be more specific
about which of Jonathan Stott's papers you're referring to I can't really
add any more.
That's a completely separate issue, not COFDM related. There isn't, AFAIK,
the same flexibility as there is in DVB-T to change the transmission
parameters to trade off capacity and signal robustness.
FWIW you could stack your loft full of aerials as long as their
correctly connected and spaced etc. But the cable I would deffo
recommend you upgrade. The new CT100 is far better than the older types
of so called Low Loss aerial cable.....
I solder all my coax plugs/sockets, i.e. push the central core right
through so that it pokes out the bit that plugs into the telly, video
etc. In the loft I split the aerial down lead into two and use a bit of
15 mm copper pipe hammered oval as a shield. Works fine. A bit of
aluminium corrosion between the junction of copper and coax plug is
bad news for reception.
HomeOwnersHub.com is a website for homeowners and building and maintenance pros. It is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.