Well I don't consider java to be programming, ;?). It's little
more than 
scripting macros, or writing DOS batch files. A bit like HTML 
programmers. Nothing much more than programming teletext pages back in 
the bronze age, and my pet ferret was tasked with those duties, the 
monkeys considered it below their dignity. :-D

Al

Richard wrote:

>Heee hee, Al, I can't wait to hear what you
will say with this factoid: I 
>think probably more than 50% of the new college kids ONLY have Java 
>experience. C/C++ are too "low level" for them...
>
>At 01:44 AM 3/3/2005, Onestone wrote:
>  
>
>>...
>>I'm obviously expected to bite here, so I will. BULLSHIT.
>>
>>I doubt you could implement any of my current designs in C on the same
>>MSP430, yet in asm I have both processing capacity and memory to spare.
>>As for the vaunted shorter  development times, another myth, actual
>>coding should be such a small percentage of a well designed product that
>>language is almost irrelevant from that perspective. The only importance
>>of language from a design viewpoint lies in the skills of those tasked
>>to program and maintain the product. It is pointless coding in asm if
>>they lack the skills, similarly it is  pointless designing for C if your
>>asm programmer can't write in C. The big difference is that only a
small
>>percentage of  C programmers are truely fluent in asm, whereas most asm
>>programmers have good C skills. The major issue is that universities are
>>churning out C and C++ programmers by the bucketful, but very few
leave
>>uni with good asm skills, why? Well part fad, part industry perception,
>>partly because C is far easier to teach, and mostly because it is far
>>easier to learn. Hell my sons been programming in C since he was 10, he
>>reckons it was easier to learn than VB.
>>
>>Al
>>
>>    
>>
>
>// richard (This email is for mailing lists. To reach me directly, please 
>use richard at imagecraft.com) 
>
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>
>  
>

Patrick Huesmann <patrick.huesmann@patr...> wrote:
Hi,

On Thu, 03 Mar 2005 20:14:48 +1030, Onestone
<onestone@ones...> wrote:
>  I doubt you could implement any of my current designs in C on the same 
>  MSP430

This may be an issue in very high-volume applications.

But the company that I work for, only does low quantity, and there you have it
the other way around: cost of parts (MCUs etc.) is almost irrelevant, whereas
development cost is crucial.

And development cost would skyrocket if we had to learn new asm languages for
each new MCU we're using. Not to mention the impact on code reuse and
portability.

... let it down! there is no real code reuse in embedded
... what do you reuse: a for cycle, a swich or a multiply
... each uC architecture must fit the purpose, target, scope of the project and
this is the direction of the effort not to inherit code lines 

>  The major issue is that universities are 
>  churning out C and C++ programmers by the bucketful, but very few
leave 
>  uni with good asm skills, why?

Why should I learn asm at university? The professors would probably teach
assembly language based on some ancient, bizarre architecture that is obsolete
even before the students receive their diploma ;)

... the purpose is to give students abilities to solve problems not to give them
diplomas (my 2 eurocents ....)

>  Hell my sons been programming in C since he was
10, he 
>  reckons it was easier to learn than VB.

I'm glad that I never had to use VB yet ;-))

... regatds, 
... avram 

regards,
Patrick


.








---------------------------------
. 



		
---------------------------------
Celebrate Yahoo!'s 10th Birthday! 
 Yahoo! Netrospective: 100 Moments of the Web 

Hi,
> >I'm glad that I never had to use VB yet
;-))
> 
> Why. It allows you to write very quick and dirty prototypes.

Why use VB for this task? Even Pascal is more portable than that.
I use C for prototyping - test & simulate on the PC, then simply copy
& paste into embedded project. That's the beauty of portable languages
;-)

> C++ was aheap of crap though, ridiculously
> verbose, and too inefficient

Well, that's at least one possible opinion.

> anmd nothing that a good asm programmer
> couldn't do without the megabytes overhead.

Yes, C++ generates runtime overhead. But this is not always the most
important thing.

You can also write object oriented software in C, in fact the first
C++ compilers were nothing but "preprocessors" that generated ANSI
C
source files. So, in fact, you can write object-oriented s/w in ASM
too.
But you will end up using a lot more lines of code, and many people
claim that LOC count is at least proportional to the number of bugs in
the application.

It's a tradeoff runtime overhead vs. "source code" overhead, and
that's the whole point of these new-fashioned languages & libraries
that try to achieve higher levels of abstraction.

For many people this is a huge benefit, and as you already said, it's
a matter of "the right tool for the job". I even did embedded stuff in
C++, and I think it's ok if the application is complex and if the
hardware can handle it.
Consider the recent hype about embedded Linux and compare the overhead
of a full-blown multi-user operating system vs. the overhead of a
small vtable that you get with C++.

Regards,
Patrick

On Thu, Mar 03, 2005 at 04:17:56AM -0800, avram ionut wrote:

> ... let it down! there is no real code reuse in
embedded

There is code reuse in embedded systems. Well, often you cannot do it at
lib-level (compile the code and put in in a lib, like std-c lib). You have
to do it at source code level. The lower level routines (sometimes C-code)
have to be rewritten to the specific hardware (e.g. SPI-interface access to
the dataflash, init, read/write byte), but the high level routines are the
same (block transfers, buffers ...). Sometimes its tricky, but it is really
possible and save me much time (and cost some time to make it reusable from
the start on) You can see that principle practically used at the RTOS that
are available in the Net. Only some files have to be adapted to the specific
controller; most of the other routines are the same.

> ... what do you reuse: a for cycle, a swich or a
multiply

Much more: the higher level routines

> Why should I learn asm at university? The
professors would probably teach
> assembly language based on some ancient, bizarre architecture that is
> obsolete even before the students receive their diploma ;)

I teached the 8051-asm (or was it Z8?) to my fellows in a 14 day course,
nobody from the teachers had experiences ;-). But I guess nobody learned it
really, it was just a quick introduction.
 
M.

My "first of all" complain against C is the amount of trust you
have to give
to few people (maybe just one) who wrote the compiler, drivers or APIs.
It is why there are so many backdoors, glitches, "blue screens", virus
and
worms: everyone is aceppting C tools like they are perfect (or, at least,
like Microsoft, why to botter if a software hangs only less than 10% of the
times?).
If your C program works fine in the PC you cannot trust it will remain
working the same way when porting to a microcontroler.

Obviously to write Assembler programs demands more time and skills but you
have the chance to cover every single possible behavior. You can be sure you
have the most efficient result and also you sometimes can fit the solution
in a smaller device.
Time-to-market issues must be accounted with all parameters. As Al and
others have said, a carefull study will save time later and well done ASM
routines are allways usefull in other applications.

I believe the lack of ASM classes in schools is like students "shooting
their legs". If you are a good C programmer when you learn ASM you will be
the better. It is also moving down the average result in education. So, if
70% of the class are afraid of studing how to understand several CPU
architectures (in order to be able to write ASM programs for any CPU) why to
push those poor students? Teach C and tell them it is portable as well as
they can put their professional lives in the hands of those few who wrote
the compilers.
Then, as end-year lecture, tell them to use free (or payd) routines
(packages) they can find somewhere to cut their development time to 1/10th.
Their companies will be so happy and will give them bonus and better job
positions... for a while... till some 12 year kid start reading an
opensource where he finds lots of special conditions not fully covered
(because the original programer intended to make a thesis demonstrative
program, not a fully verified one) and then a new virus is born.
Someone could tell me why in the hell cellphones can get viruses?

Let's see what will happen when Zigbee becomes a must: several IC vendors
will offer a "free design references" that will be used for everyone
"to
save design time" and few years(months) later: bang! A Zigbee virus will be
there... or worst: imagine if you have, say, 129 devices in the network all
of CPUs will call a non existent routine and WDT will pop everywhere...

Would you say that Microsoft do not use certified routines? Probably not,
then how can you explain the number of flaws? So, it is obvious there are
lots and lots of well writen C (and ASM) programs but the few bad ones still
making damage...




-----Original Message-----
From: Patrick Huesmann [mailto:patrick.huesmann@patr...] 
Sent: Thursday, March 03, 2005 11:52 AM
To: Onestone
Cc: msp430@msp4...
Subject: Re: [msp430] TimerA ISR



Hi,
> >I'm glad that I never had to use VB yet
;-))
> 
> Why. It allows you to write very quick and dirty prototypes.

Why use VB for this task? Even Pascal is more portable than that. I use C
for prototyping - test & simulate on the PC, then simply copy & paste
into
embedded project. That's the beauty of portable languages
;-)

> C++ was aheap of crap though, ridiculously
> verbose, and too inefficient

Well, that's at least one possible opinion.

> anmd nothing that a good asm programmer
> couldn't do without the megabytes overhead.

Yes, C++ generates runtime overhead. But this is not always the most
important thing.

You can also write object oriented software in C, in fact the first
C++ compilers were nothing but "preprocessors" that generated ANSI
C
source files. So, in fact, you can write object-oriented s/w in ASM too. But
you will end up using a lot more lines of code, and many people claim that
LOC count is at least proportional to the number of bugs in the application.

It's a tradeoff runtime overhead vs. "source code" overhead, and
that's the
whole point of these new-fashioned languages & libraries that try to achieve
higher levels of abstraction.

For many people this is a huge benefit, and as you already said, it's a
matter of "the right tool for the job". I even did embedded stuff in
C++, and I think it's ok if the application is complex and if the
hardware can handle it.
Consider the recent hype about embedded Linux and compare the overhead of a
full-blown multi-user operating system vs. the overhead of a small vtable
that you get with C++.

Regards,
Patrick


.

 
Yahoo! Groups Links



 




-- 
Internal Virus Database is out-of-date.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 10/2/2005
 

Hi,

--- In msp430@msp4..., "augusto einsfeldt" <aee@t...> wrote:
> My "first of all" complain against C is
the amount of trust you have
to give
> to few people (maybe just one) who wrote the
compiler, drivers or APIs.

Yes, that's true, you must trust s.o. else's code, even if you
don't
use standard library functions, you have to trust the compiler. And
compilers are not always perfect, they do have bugs at times.

> It is why there are so many backdoors, glitches,
"blue screens",
virus and
> worms: everyone is aceppting C tools like they are
perfect (or, at
least,
> like Microsoft, why to botter if a software hangs
only less than 10%
of the
> times?).

Perhaps, but then we'd be talking about C/C++ vs. Java, C# etc.

> If your C program works fine in the PC you cannot
trust it will remain
> working the same way when porting to a microcontroler.

If both compilers are standards-compliant and your code doesn't depend
on platform-specific features (API's, data type size/endian etc.),
then it should do the same. Of course, it needs to be tested again,
nevertheless.
 
> Let's see what will happen when Zigbee
becomes a must: several IC
vendors
> will offer a "free design references"
that will be used for everyone "to
> save design time" and few years(months) later: bang! A Zigbee virus
will be
> there... or worst: imagine if you have, say, 129
devices in the
network all
> of CPUs will call a non existent routine and WDT
will pop everywhere...

Last time I checked, there was only a low-level MAC really part of the
zigbee standard (no real network layer or even application layer).

OK, I'm also surprised that cellphone worms are around now. I think
it's because the phones standardize on Symbian OS etc.
But then, this allows you to write custom s/w apps for the phone
(http://bemused.sf.net/ for example) so is it a good or a bad thing?

Regards,
Patrick

I have to dispute that there is no real reuse in embedded stuff. I have
done a few items on the AVR that had a MIDI interface for talking to
keyboards. The actual things being built were quite different but a
large amount of the code was similar... Surely reuse? We had a software
manager here who had lots of interesting terms for the methodology of
writing code... One of my favourites was "scavenging". Which again is
reuse where you cut and paste useful sections of code out of previous
projects... Again reuse. If you structure your reuse properly,
regardless of assembler or C, then fixing up the serial port class, for
instance, only happens once, not five or six times.

On the subject of C vs ASM I would have to say that I am sure that I
would always of picked Z80 assembler over any 'high level' language
but
as I have had to work in teams I must admit that C is just a lot easier.
If a project is written in ASM then there do seem to be more
opportunities for writing cryptic code (especially on the PIC). I am not
saying that people don't do it in C it is just, in my experience, if you
are picking up a project that needs some work it is usually easier to
understand somebody's C over somebody else's ASM. This can be quite a
big consideration for companies which have long development cycles on a
project and an associated turn over of people working on that project.
As always, this is a generalisation....

 

-----Original Message-----
From: avram ionut [mailto:avramionut_m@avra...] 
Sent: Thursday, 3 March 2005 8:18 PM
To: msp430@msp4...
Subject: Re: [msp430] TimerA ISR




Patrick Huesmann <patrick.huesmann@patr...> wrote:
Hi,

On Thu, 03 Mar 2005 20:14:48 +1030, Onestone <onestone@ones...>
wrote:
>  I doubt you could implement any of my current
designs in C on the 
> same  MSP430

This may be an issue in very high-volume applications.

But the company that I work for, only does low quantity, and there you
have it the other way around: cost of parts (MCUs etc.) is almost
irrelevant, whereas development cost is crucial.

And development cost would skyrocket if we had to learn new asm
languages for each new MCU we're using. Not to mention the impact on
code reuse and portability.

... let it down! there is no real code reuse in embedded ... what do you
reuse: a for cycle, a swich or a multiply ... each uC architecture must
fit the purpose, target, scope of the project and this is the direction
of the effort not to inherit code lines 

>  The major issue is that universities are 
churning out C and C++ 
> programmers by the bucketful, but very few leave  uni with good asm 
> skills, why?

Why should I learn asm at university? The professors would probably
teach assembly language based on some ancient, bizarre architecture that
is obsolete even before the students receive their diploma ;)

... the purpose is to give students abilities to solve problems not to
give them diplomas (my 2 eurocents ....)

>  Hell my sons been programming in C since he was
10, he  reckons it 
> was easier to learn than VB.

I'm glad that I never had to use VB yet ;-))

... regatds,
... avram 

regards,
Patrick


.








---------------------------------
. 



		
---------------------------------
Celebrate Yahoo!'s 10th Birthday! 
 Yahoo! Netrospective: 100 Moments of the Web 





.

 
Yahoo! Groups Links



 



--
This email is confidential and intended solely for the use of the individual to
whom it is addressed.  
Any views or opinions presented are solely those of the author and do not
necessarily represent those of NAUTRONIX LTD.

If you are not the intended recipient, you have received this email in error and
use, dissemination, forwarding, printing, or copying of this email is strictly
prohibited.  If you have received this email in error please contact the sender.
  

Although our computer systems use active virus protection software, and we take
various measures to reduce the risk of viruses being transmitted in e-mail
messages and attachments sent from this company, we cannot guarantee that such
e-mail messages and attachments are free from viruses on receipt.  It is a
condition of our using e-mail to correspond with you, that any and all liability
on our part arising directly or indirectly out of any virus is excluded.  Please
ensure that you run virus checking software on all e-mail messages and
attachments before reading them.

You have a point. 
Although I am ASM defender when you have team design C code is much easier
to handle.
Also, ASM software in bigger CPUs is just nonsense. This C vs ASM talk is,
of course, restricted to microcontrollers, CPUs with small amount of memory
or when one needs the ultimate performance of limited system.
My biggest ASM code needs near 46KB and it is amazing how often I find
someone doing even faster and smaller solutions for a piece of code already
well dry.


-----Original Message-----
From: Tim Wade [mailto:rtdb.wade@rtdb...] 
Sent: Thursday, March 03, 2005 10:06 PM
To: msp430@msp4...
Subject: RE: [msp430] TimerA ISR



I have to dispute that there is no real reuse in embedded stuff. I have done
a few items on the AVR that had a MIDI interface for talking to keyboards.
The actual things being built were quite different but a large amount of the
code was similar... Surely reuse? We had a software manager here who had
lots of interesting terms for the methodology of writing code... One of my
favourites was "scavenging". Which again is reuse where you cut and
paste
useful sections of code out of previous projects... Again reuse. If you
structure your reuse properly, regardless of assembler or C, then fixing up
the serial port class, for instance, only happens once, not five or six
times.

On the subject of C vs ASM I would have to say that I am sure that I would
always of picked Z80 assembler over any 'high level' language but as I
have
had to work in teams I must admit that C is just a lot easier. If a project
is written in ASM then there do seem to be more opportunities for writing
cryptic code (especially on the PIC). I am not saying that people don't do
it in C it is just, in my experience, if you are picking up a project that
needs some work it is usually easier to understand somebody's C over
somebody else's ASM. This can be quite a big consideration for companies
which have long development cycles on a project and an associated turn over
of people working on that project. As always, this is a generalisation....

 

-----Original Message-----
From: avram ionut [mailto:avramionut_m@avra...] 
Sent: Thursday, 3 March 2005 8:18 PM
To: msp430@msp4...
Subject: Re: [msp430] TimerA ISR




Patrick Huesmann <patrick.huesmann@patr...> wrote:
Hi,

On Thu, 03 Mar 2005 20:14:48 +1030, Onestone <onestone@ones...>
wrote:
>  I doubt you could implement any of my current designs in C on the
> same  MSP430

This may be an issue in very high-volume applications.

But the company that I work for, only does low quantity, and there you have
it the other way around: cost of parts (MCUs etc.) is almost irrelevant,
whereas development cost is crucial.

And development cost would skyrocket if we had to learn new asm languages
for each new MCU we're using. Not to mention the impact on code reuse and
portability.

... let it down! there is no real code reuse in embedded ... what do you
reuse: a for cycle, a swich or a multiply ... each uC architecture must fit
the purpose, target, scope of the project and this is the direction of the
effort not to inherit code lines 

>  The major issue is that universities are 
churning out C and C++
> programmers by the bucketful, but very few leave  uni with good asm 
> skills, why?

Why should I learn asm at university? The professors would probably teach
assembly language based on some ancient, bizarre architecture that is
obsolete even before the students receive their diploma ;)

... the purpose is to give students abilities to solve problems not to give
them diplomas (my 2 eurocents ....)

>  Hell my sons been programming in C since he was
10, he  reckons it
> was easier to learn than VB.

I'm glad that I never had to use VB yet ;-))

... regatds,
... avram 

regards,
Patrick


.








---------------------------------
. 



		
---------------------------------
Celebrate Yahoo!'s 10th Birthday! 
 Yahoo! Netrospective: 100 Moments of the Web 





.

 
Yahoo! Groups Links



 



--
This email is confidential and intended solely for the use of the individual
to whom it is addressed.  
Any views or opinions presented are solely those of the author and do not
necessarily represent those of NAUTRONIX LTD.

If you are not the intended recipient, you have received this email in error
and use, dissemination, forwarding, printing, or copying of this email is
strictly prohibited.  If you have received this email in error please
contact the sender.   

Although our computer systems use active virus protection software, and we
take various measures to reduce the risk of viruses being transmitted in
e-mail messages and attachments sent from this company, we cannot guarantee
that such e-mail messages and attachments are free from viruses on receipt.
It is a condition of our using e-mail to correspond with you, that any and
all liability on our part arising directly or indirectly out of any virus is
excluded.  Please ensure that you run virus checking software on all e-mail
messages and attachments before reading them.

.

 
Yahoo! Groups Links



 




-- 
Internal Virus Database is out-of-date.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.7 - Release Date: 10/2/2005
 

patrick_huesmann wrote:

>
>Last time I checked, there was only a low-level MAC really part of the
>zigbee standard (no real network layer or even application layer).
>
>OK, I'm also surprised that cellphone worms are around now. I think
>it's because the phones standardize on Symbian OS etc.
>But then, this allows you to write custom s/w apps for the phone
>(http://bemused.sf.net/ for example) so is it a good or a bad thing?
>  
>

To be able to upload a virus to a mobile phone implies that there is 
external access to control the telephones functions. ie the telephone 
company has full control over your phone. The implications of this are 
not good.

Al

I agree entirely I have huge libraries in asm that I plug into new 
designs. The code is tested and proven, and typically more adaptable 
than c style libraries. Ie I have code for PWM on a single timer, code 
for PWM on dual timers, with or without hardware linked I/O pins. i have 
graphics routines for character displays etc etc. translation is simple.

When I start a new project I have 4 files that start every project. 
STD_DEFxxx, IO.asm, HDR.asm and MAIN.asm. In fact you could probably 
include INIT.asm in that as well. the def file holds all the definitions 
for just one micro. IO gives my IO allocation map, HDR holds constants, 
RAM allocation etc, INITxxx has clock stabilisation routines and shell 
initialisations for a specific micro MAIN holds the glue stuff, oh ISR 
holds an ISR template, and ADC12x holds the ISRs and setup for the 
analog sub-system. I have variants of this depending on which mode I am 
using the A/D in.I then have things like KBD, LCDC, LCDG, LCDCG, 
FLASHLIB, ADXL, ADXRS, SPI, COMMx, where there are different types for 
different protocols. Most of these require just afew constants at the 
start of the file to be configured. So re-use lives at a modular level.

I suspect Augusto was implying the wholesale re-use of programs doesn't 
really happen in embedded. This I find especially true when it comes to 
updating an old system written by someone else. I've mentioned the 
litany of disastrous code I've seen before, but it sure aint re-uable.

Al

Tim Wade wrote:

>I have to dispute that there is no real reuse in
embedded stuff. I have
>done a few items on the AVR that had a MIDI interface for talking to
>keyboards. The actual things being built were quite different but a
>large amount of the code was similar... Surely reuse? We had a software
>manager here who had lots of interesting terms for the methodology of
>writing code... One of my favourites was "scavenging". Which again
is
>reuse where you cut and paste useful sections of code out of previous
>projects... Again reuse. If you structure your reuse properly,
>regardless of assembler or C, then fixing up the serial port class, for
>instance, only happens once, not five or six times.
>
>On the subject of C vs ASM I would have to say that I am sure that I
>would always of picked Z80 assembler over any 'high level'
language but
>as I have had to work in teams I must admit that C is just a lot easier.
>If a project is written in ASM then there do seem to be more
>opportunities for writing cryptic code (especially on the PIC). I am not
>saying that people don't do it in C it is just, in my experience, if
you
>are picking up a project that needs some work it is usually easier to
>understand somebody's C over somebody else's ASM. This can be
quite a
>big consideration for companies which have long development cycles on a
>project and an associated turn over of people working on that project.
>As always, this is a generalisation....
>
> 
>
>-----Original Message-----
>From: avram ionut [mailto:avramionut_m@avra...] 
>Sent: Thursday, 3 March 2005 8:18 PM
>To: msp430@msp4...
>Subject: Re: [msp430] TimerA ISR
>
>
>
>
>Patrick Huesmann <patrick.huesmann@patr...> wrote:
>Hi,
>
>On Thu, 03 Mar 2005 20:14:48 +1030, Onestone <onestone@ones...>
>wrote:
>  
>
>> I doubt you could implement any of my current designs in C on the 
>>same  MSP430
>>    
>>
>
>This may be an issue in very high-volume applications.
>
>But the company that I work for, only does low quantity, and there you
>have it the other way around: cost of parts (MCUs etc.) is almost
>irrelevant, whereas development cost is crucial.
>
>And development cost would skyrocket if we had to learn new asm
>languages for each new MCU we're using. Not to mention the impact on
>code reuse and portability.
>
>... let it down! there is no real code reuse in embedded ... what do you
>reuse: a for cycle, a swich or a multiply ... each uC architecture must
>fit the purpose, target, scope of the project and this is the direction
>of the effort not to inherit code lines 
>
>  
>
>> The major issue is that universities are  churning out C and C++ 
>>programmers by the bucketful, but very few leave  uni with good asm 
>>skills, why?
>>    
>>
>
>Why should I learn asm at university? The professors would probably
>teach assembly language based on some ancient, bizarre architecture that
>is obsolete even before the students receive their diploma ;)
>
>... the purpose is to give students abilities to solve problems not to
>give them diplomas (my 2 eurocents ....)
>
>  
>
>> Hell my sons been programming in C since he was 10, he  reckons it 
>>was easier to learn than VB.
>>    
>>
>
>I'm glad that I never had to use VB yet ;-))
>
>... regatds,
>... avram 
>
>regards,
>Patrick
>
>
>.
>
>
>
>
>
>
>
>
>---------------------------------
>. 
>
>
>
>		
>---------------------------------
>Celebrate Yahoo!'s 10th Birthday! 
> Yahoo! Netrospective: 100 Moments of the Web 
>
>
>
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>--
>This email is confidential and intended solely for the use of the individual
to whom it is addressed.  
>Any views or opinions presented are solely those of the author and do not
necessarily represent those of NAUTRONIX LTD.
>
>If you are not the intended recipient, you have received this email in error
and use, dissemination, forwarding, printing, or copying of this email is
strictly prohibited.  If you have received this email in error please contact
the sender.   
>
>Although our computer systems use active virus protection software, and we
take various measures to reduce the risk of viruses being transmitted in e-mail
messages and attachments sent from this company, we cannot guarantee that such
e-mail messages and attachments are free from viruses on receipt.  It is a
condition of our using e-mail to correspond with you, that any and all liability
on our part arising directly or indirectly out of any virus is excluded.  Please
ensure that you run virus checking software on all e-mail messages and
attachments before reading them.
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>
>  
>