Searching \ for '[PIC] Why let the atmel guys have all the fun? - P' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Why let the atmel guys have all the fun? - P'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Why let the atmel guys have all the fun? - P'
2009\03\19@183328 by solarwind

picon face
The arduino is a huge hit. Unfortunately, it uses the atmel chips.
Well, some like atmel chips, but I don't like them.

The arduino is awesome. It's extensible, easy to use, clean, small and fun.

So why don't we make our own? With the PIC, that is. I know it's
definitely possible. The 28 pin 16Fs and 18Fs can do self write to
flash. So if we get a USB PIC or use a normal PIC with a FT232 type
chip, we can make a standalone development board that can load
programs via USB. The bootloader shouldn't be hard to make either. And
we also have really nice compilers: CCS, Microchip, HITECH which I
believe far outperform atmel's in terms of code size optimization.
Also, our 18F chips are way cooler than atmel's.

So why don't we do it?

Some guy already made a PIC32 standalone dev board called the UBW32.
So let's do this with the 8 bit chips?

--
solarwind

2009\03\19@202926 by Tamas Rudnai

face picon face
There are tons of such, even Microchip is producing demo boards you can use
like the PICdem full-speed USB:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en021940&part=DM163025

That is $60 USD, however, you can download the PDF and build your circuit as
the schematics included.

Tamas


On Thu, Mar 19, 2009 at 10:33 PM, solarwind <spam_OUTx.solarwind.xTakeThisOuTspamgmail.com> wrote:

{Quote hidden}

> -

2009\03\19@203820 by solarwind

picon face
I'm talking about something much smaller and cheaper like the Arduino.
$60 is way too much and that is way too big.

2009\03\19@204043 by Peter Loron

flavicon
face
On Mar 19, 2009, at 3:33 PM, solarwind wrote:

{Quote hidden}

The hard part about mirroring the success of the Arduino platform  
isn't the hardware. It is the development environment. It is _very_  
easy to use even if you don't know C or anything about programming  
microcontrollers. The libraries are extensive and make it easy to do  
many common tasks without fiddling with pointers, flags, ASM, or low  
level pin manipulation.

Giving a novice any of the aforementioned IDEs wouldn't make for an  
appealing environment.

-Pete

2009\03\19@204156 by Jesse Lackey

flavicon
face
If the C compiler isn't free, PICduino isn't going to go very far.  The
is a larger discussion, but for most hobbyist purposes quality of the C
compiler isn't very important; free is.  People go to significant
lengths to get stuff free, wouldn't you agree?

Now there are ways to get not-free software for free.  But it is a
serious impediment, and no academic institution will blatantly disregard
copyrights, so all the "physical computing" classes out there - and
there are an astonishing number - won't consider spending $100 or more
per copy when there is a free alternative that requires no licensing
hassles whatsoever.  I know offhand of several physical computing
courses that dumped PIC for AVR for exactly this reason.

There is a port of SDCC to PICs in progress, but from what I understand
it is pretty spotty.  If it becomes very solid then it is a contender.

BTW, I think the AVR GCC toolchain is pretty good.  It is a breath of
fresh air, having an industrial-strength, ANSI compliant compiler after
using CCS for 5 years.

Just my 2c on the dynamics of the business.

J



solarwind wrote:
{Quote hidden}

2009\03\19@204356 by Xiaofan Chen

face picon face
On Fri, Mar 20, 2009 at 6:33 AM, solarwind <.....x.solarwind.xKILLspamspam@spam@gmail.com> wrote:
> So why don't we make our own? With the PIC, that is. I know it's
> definitely possible. The 28 pin 16Fs and 18Fs can do self write to
> flash. So if we get a USB PIC or use a normal PIC with a FT232 type
> chip, we can make a standalone development board that can load
> programs via USB. The bootloader shouldn't be hard to make either.

This is okay.

> And we also have really nice compilers: CCS, Microchip, HITECH
> which I believe far outperform atmel's in terms of code size optimization.

This is one of the main problem. None of these compilers are
free for the full version.

Take note AVR architecture does have advantages against
PIC18 in terms of C code size. So I think you are not correct
in terms of code size. Both IAR (Commercial) and GCC (free,
open source) for AVR produce excellent code size.

> Also, our 18F chips are way cooler than atmel's.

Not really true. Both has its advantages.

Xiaofan

2009\03\19@205928 by solarwind

picon face
I have used SDCC years ago and it worked fine back then. Seriously.
But I do hope that the software side of this starts picking up,
especially after Microchip purchased HITECH.

2009\03\19@220926 by William \Chops\ Westfield

face picon face
>> What is arduino and why is it so popular?
>>  I assume it's like stamp for avr.

Philosophically, the Arduino is very much like the Parallax "Basic  
Stamp", in that they've implemented hardware and environment (program  
functionality, IDE, HW and SW expandability) that are very  
"approachable" by users (and potential users) without a lot of  
experience.  UNLIKE the Stamps, the Arduino uses a bare AVR chip and a  
real compiler, making it somewhat more attractive to the non-
beginner.  And MUCH faster than a stamp.  You can clone Arduino cores  
at about $3 each (ATmega8 + resonator), or you can neglect the IDE  
entirely and just use the hardware as a convenient USB-connectable  
development board.  And finally, it has that whole "open source"  
mystique, for whatever that's worth (actually, they're treading some  
interesting ground there.  I don't know if it's all good, but I'm  
following "How Things Work Out" with some considerable interest.)


> The arduino is awesome.  ... Well, some like atmel chips, but I  
> don't like them.


Aw.  No free samples ?  (dig, dig.)


> So why don't we make our own [PIC-based arduino clone]?

Well, that's an interesting question.  I figure a USB Bit-whacker is  
90% of the way to being Arduino-like.  Talks directly to USB, includes  
bootloader; all it needs is a painless IDE and a community.  
Furthermore, I'm somewhat anxiously awaiting a 32-bit super-Arduino.  
I used to think an ARM was a natural target (and we could certainly  
use an easier all-in-one ARM environment, IMO.)   But the PIC32 should  
work equally well (but not well enough for this idea to progress in  
the PIC32 design contest.  Sniff.)  The low-end Freescale Coldfire  
chips are also potential candidates.  And there is already a PIC32  
based USB-bootwhacker, too.  (although, part of the attraction of  
Arduino is those DIP-based ATmega chips that you can take out and put  
elsewhere really easily.  None of the 32bit options would allow that.)

I think Arduino benefits from the "easy install" of the IDE.  There is  
no separate compiler to install; the package includes its own copy of  
gcc-avr (except on linux, for reasons I don't quite understand but  
don't care very much about.)  This pretty-much requires an open-source  
compiler.  You can't very well package up the (free) Lite HiTech C in  
a third party IDE (I can't even see being able to package up the gcc-
based Microchip free-version compilers like this.)

The "community" thing is tough.  Creating a "community" is a bit like  
creating a "cult film" - if you set out TRYING to do so, you almost  
certainly do a poor job (compared to the real thing, anyway.)  There  
are assorted PIC communities, but they aren't like the arduino  
community.   There's the basic stamp community, which is closer, but I  
don't see them converting to C :-)

BillW


2009\03\20@043753 by David Harris

picon face
William "Chops" Westfield wrote:
> Furthermore, I'm somewhat anxiously awaiting a 32-bit super-Arduino.  
>  

Try http://lusorobotica.com/index.php/topic,675.0.html  --- not quite
released into the wild yet.

David

2009\03\20@054132 by William \Chops\ Westfield

face picon face

On Mar 20, 2009, at 1:37 AM, David Harris wrote:
>> somewhat anxiously awaiting a 32-bit super-Arduino.
>>
> Try http://lusorobotica.com/index.php/topic,675.0.html  --- not quite
> released into the wild yet.

Yes, I know.  But not 32 bits and not faster than the orignal  
arduino.  I was lusting after 72MHz ST32M Cortex-M3s, 80Mhz PIC32s, or  
at least 48MHz MCF51JM128 coldfires. (ah, the lovely 68000 instruction  
set...)

BillW

2009\03\20@062213 by Michael Rigby-Jones

picon face


> -----Original Message-----
> From: piclist-bouncesspamKILLspammit.edu [.....piclist-bouncesKILLspamspam.....mit.edu] On
Behalf
{Quote hidden}

quite
> > released into the wild yet.
>
> Yes, I know.  But not 32 bits and not faster than the orignal
> arduino.  I was lusting after 72MHz ST32M Cortex-M3s, 80Mhz PIC32s, or
> at least 48MHz MCF51JM128 coldfires. (ah, the lovely 68000 instruction
> set...)
>
> BillW

Yes, an STM32 based Arduino would be very worthwhile. I don't see the
point in making an 18F PIC based board when a) The AVR ones are so
cheap, and the AVR is an extremely capable device (more so than the 18F
in many respects) and b) The 18F does not have the free compiler support
of the AVR.

The Cortex M parts are incredibly powerful micros that cost barely more,
and often less than 18F PIC's and AVRs ($1.80 for a 32k, 48 pin device,
$3.60 for 128k, 100pin in volume).  They also have solid support in the
GCC compiler.

The only thing that might put of some is that they are all surface mount
parts, but that wouldn't be a problem if you are buying a ready made
prototype board.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2009\03\20@070608 by DVD

flavicon
face
>
>  
> The Cortex M parts are incredibly powerful micros that cost barely more,
> and often less than 18F PIC's and AVRs ($1.80 for a 32k, 48 pin device,
> $3.60 for 128k, 100pin in volume).  They also have solid support in the
> GCC compiler.
>
>  
I talked to some people on one electronics fair and they recommended M3
Cortex microcontrollers, so I bought this kit in a sale:
www.stm32circle.com/resources/stm32primer2.php
Something like this has a chance to be "development platform" for
masses, but a few things are very important - price, real usability and
availability.

To solarwind: I didn't get the point of Arduino madness, it's like any
other kit. Why do we all need to have the same one? Buy one that matches
your needs or do your own design. It's that simple. Kits are meant to
helpful before doing your own design not buy ten of them and embed them
everywhere you can.

David

2009\03\20@071100 by olin piclist

face picon face
solarwind wrote:
> The arduino is a huge hit. Unfortunately, it uses the atmel chips.
> Well, some like atmel chips, but I don't like them.
>
> The arduino is awesome. It's extensible, easy to use, clean, small and
> fun.
>
> So why don't we make our own? With the PIC, that is.

I don't know what a arduino is, but this sounds like our ReadyBoard-02
(http://www.embedinc.com/products).  This comes with all the infrastructure
around the PIC to run it, makes various power supply voltages available all
derived from the USB, and has a decent size breadboard area for you to add
your own circuit.  It also comes with open source firmware and host software
that implements a bi-directional stream of bytes from a app on your PC to
your firmware app on the PIC.  This includes example programs and PIC app to
wiggle pins from the PC right out of the box.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\03\20@090938 by Russell McMahon

face
flavicon
face
> I don't know what a arduino is,*

But, Gargoyle, not surprisingly, does.

  http://www.arduino.cc/

       "Arduino is an open-source electronics prototyping platform based on
flexible, easy-to-use hardware and software. It's intended for artists,
designers, hobbyists, and anyone interested in creating interactive objects
or environments."

It's a state of mind, a complete development environment, so

> but this sounds like our ReadyBoard-02
> (http://www.embedinc.com/products).

no.

It allows you to implement standalone systems based on as little as a
minimum hardware implementation of a given processor. Open source code /
feee compiler / C like language but, users generally report, an easier
learning curve.

Software

   http://www.arduino.cc/en/Main/Software

  "The open-source Arduino environment makes it easy to write code and
upload it to the i/o board. It runs on Windows, Mac OS X, and Linux. The
environment is written in Java and based on Processing, avr-gcc, and other
open source software."


 Russell

* It's presumably not worth noting that  ...., ah, forget it. (deletes
paragraph) ...


2009\03\20@103443 by William \Chops\ Westfield

face picon face

On Mar 20, 2009, at 6:09 AM, Russell McMahon wrote:

>> [Olin] but this sounds like our ReadyBoard-02
>> (http://www.embedinc.com/products).
>
> no.

Well, hardware-wise it's not dissimilar.

> It's intended for artists, designers, hobbyists, and anyone  
> interested in creating interactive objects or environments.

INTENT-wise, it's a LOT different, I think.  The Readyboard is aimed  
at professionals wanting to quickly prototype something.  The mere  
thought of Olin interacting with some of the "Artists" I've talked to  
on the Arduino forums is ...  Making me smile quite broadly...

It's all very well to claim to be aimed at beginners without much  
experience, and quite another thing to SUCEED it both attracting such  
users and getting them to be able to do what they want.

BillW

2009\03\20@111616 by Nathan House

picon face
>If the C compiler isn't free, PICduino isn't going to go very far.  The
>is a larger discussion, but for most hobbyist purposes quality of the C
>compiler isn't very important; free is.

Microchip provides free versions of their compilers. The only difference *I
think* is that the paid version is "optimized" or something. I use the free
versions of the C18 and C30 compilers and they work just fine with MPLAB.

So you DON'T have to pay anything for an IDE.

Nathan

2009\03\20@112826 by Tony Smith

flavicon
face
> The arduino is a huge hit. Unfortunately, it uses the atmel chips.
> Well, some like atmel chips, but I don't like them.
>
> The arduino is awesome. It's extensible, easy to use, clean, small and
fun.
>
> So why don't we make our own? With the PIC, that is. I know it's
> definitely possible.


The old joke is a camel is a horse designed by committee.

The PicList couldn't organise a piss-up in a brewery, as the saying goes.
That's true for any large group full of opinionated individuals though, or
even not-so-opinionated ones.  The opinionated individuals could do it (and
some have to various degrees), but no doubt not to the satisfaction of the
others.

It's more than just hardware, you need the software too.

You're probably looking at a six month discussion on tab-to-space
conversion, ranging from 'no' to '8 spaces'.  Then you're onto trivial
matters like where the braces should go.  I once added a switch to a program
to change the spelling of a word (which for the life of me I can't remember
now) as various factions put in change requests because it was spelt
'wrong'.  (Dispatch / Despatch!  That's it!).

The most obvious equivalent in the Pic world is the BasicStamp by Parallax.
It's been going for at least 10 years, I'm not sure if it actually uses a
Pic, they were SX (Scenix Pic clones) for a while.

The PicAxe by Revolution is as basic (lol) as you can get, being just a
pre-programmed chip.  Like the Stamp it runs interpreted Basic, and has its
own IDE.  Much cheaper than the Stamp (about x2 the price of a Pic blank)
but no support board, BYO breadboard.

The Stamp & the PicAxe are targeted at the education market, but still
perfectly ok for hobbyist and prototype people.

There's also ooPic and a few others.

After you finish your calculator, write up a spec and see who's interested.

Tony

2009\03\20@125906 by peter green

flavicon
face

> Microchip provides free versions of their compilers. The only difference *I
> think* is that the paid version is "optimized" or something. I use the free
> versions of the C18 and C30 compilers and they work just fine with MPLAB.
>  
Free as in beer yes but not FOSS and that is IMO a problem for building
something ardunio like arround it for a few reasons.

Firstly while C18 is kinda C it is somewhat quirky. For example it does
not have sensible handling of the >> operator for negative numbers
(there are workarrounds for this but they require great care), it lacks
a unified pointer type meaning a lot of routines end up with two copies
and so on. If it was FOSS someone could make a fixed fork but as it is
we are stuck with it.

Secondly it may well forbid distributing your soloution as a whole (not
sure on this, the license agreement for C18 student edition doesn't seem
to be easilly availible online)

Thirdly it means linux distrbutions are unlikely to accept you or will
shunt you off into a "non-free" area that is likely to be disabled by
default.

Finally it means you won't get the support of the FOSS crowd.

2009\03\20@131946 by solarwind

picon face
On Fri, Mar 20, 2009 at 5:21 AM, Michael Rigby-Jones
<EraseMEMichael.Rigby-Jonesspam_OUTspamTakeThisOuTbookham.com> wrote:
> cheap, and the AVR is an extremely capable device (more so than the 18F
> in many respects) and b) The 18F does not have the free compiler support
> of the AVR.

I'd love to hear how the AVR is more capable than an 18F. Please explain.

2009\03\20@133120 by solarwind

picon face
On Fri, Mar 20, 2009 at 10:26 AM, Tony Smith <ajsmithspamspam_OUTbeagle.com.au> wrote:
> After you finish your calculator, write up a spec and see who's interested.

I'm still waiting for the damn tactile switches and the rest of my
parts from Futurlec to arrive. They literally take more than a month
to ship to Canada...


--
solarwind

2009\03\20@142927 by M. Adam Davis

face picon face
I believe the best course of action is simply take the arduion
software (open source) and reconfigure it (replace GCC, or alter the
complie options) to target MIPS instead of AVR.

Then use the PIC32 (MIPS based core).

A bunch of files will need to be created or altered so that everything
maps over correctly.

But at the end of the day, I think the best bet is simply re-target
Arduino in such a way that it can be included in the main product and
the picduino is simply a new hardware platform with everythign else
remaining the same.

I don't believe there's a good reason to ditch all the good work
that's already been put into arduino, if the intent is simply to give
more hardware options.

Further, no one has ported the arduino over to a high performance AVR
yet anyway - if someone were to provide a 32 bit, 80MHz hardware
platform then a bunch of people would jump on it.  Many artists are
stuck hooking their arduinos up to computers or fiddling with
expensive linux platforms because there's nothing inbetween the PC and
the arduino in terms of performance.

It's non trivial, for sure, but it's easier than doing the whole
project over from scratch.

Arduino is simply Processing applied to embedded processors.  Ignore
the fact that only AVR implementations exist at the moment.

-Adam

On Fri, Mar 20, 2009 at 11:26 AM, Tony Smith <@spam@ajsmithKILLspamspambeagle.com.au> wrote:
{Quote hidden}

>

2009\03\20@144341 by solarwind

picon face
On Fri, Mar 20, 2009 at 2:29 PM, M. Adam Davis <KILLspamstienmanKILLspamspamgmail.com> wrote:
> I believe the best course of action is simply take the arduion
> software (open source) and reconfigure it (replace GCC, or alter the
> complie options) to target MIPS instead of AVR.
>
> Then use the PIC32 (MIPS based core).

This is definately possible. The C32 gcc compiler source code has been released:

www.nabble.com/PIC32-C32-GCC-Source-Code-Released-td13598312.html
mcuee.blogspot.com/2007/11/building-microchip-pic32-gcc-compiler.html

2009\03\20@144457 by solarwind

picon face
And this is cool:
www.sparkfun.com/commerce/product_info.php?products_id=8971

2009\03\20@154209 by Michael Rigby-Jones

picon face


> -----Original Message-----
> From: RemoveMEpiclist-bouncesTakeThisOuTspammit.edu [spamBeGonepiclist-bouncesspamBeGonespammit.edu] On
Behalf
> Of solarwind
> Sent: 20 March 2009 17:20
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC] Why let the atmel guys have all the fun? - PICduino
-
>
> On Fri, Mar 20, 2009 at 5:21 AM, Michael Rigby-Jones
> <TakeThisOuTMichael.Rigby-JonesEraseMEspamspam_OUTbookham.com> wrote:
> > cheap, and the AVR is an extremely capable device (more so than the
18F
> > in many respects) and b) The 18F does not have the free compiler
support
> > of the AVR.
>
> I'd love to hear how the AVR is more capable than an 18F. Please
explain.

I do hope you aren't trying to start a religious war, all micros have
their strong and weak points including the PIC and the AVR.  However,
I'll take the request at face value.  Off the top of my head the AVR
offers the following advantages:

Not limited to a single 8 bit accumulator (W register).  The AVR has 32
registers, most instructions can use any as the destination, some can
only use the top 16.

Completely non-banked architecture.  Not so much of a problem when
coding in C, but adds overhead to the code.

A proper stack, i.e. you get a proper 16 bit stack pointer, no call
depth limitation other than memory size.  A 18F PIC has 31 deep hardware
stack.  You can extend this using software, but with significant
overhead compared to the AVR.

Faster for a given clock frequency.  PIC nominally executes 1
instruction per 4 clock cycles (some instructions take longer), AVR
executes one instruction per clock cycle (again, some instructions take
longer).

Proper vectored interrupts.  This is one of the best features IMO, no
longer do you have to add a bunch of code to work out why you landed at
one of two interrupt vectors, and nested interrupts become much easier,
if you require them.

The AVR has far superior bootloader support, including the ability to
move interrupt vectors into protected bootloader memory and the ability
to continue executing code whilst writing to program memory.  This
single feature has ruled out the PIC on a number of projects I have
worked on.

Superior debugging support; either a very fast JTAG port or 'Debugwire'
which uses only the reset pin.


The PIC has it's own strengths however, and I'm certainly not suggesting
that the AVR is the best fit for all applications.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2009\03\20@160940 by Vitaliy

flavicon
face
Michael Rigby-Jones wrote:
> The AVR has far superior bootloader support, including the ability to
> move interrupt vectors into protected bootloader memory and the ability
> to continue executing code whilst writing to program memory.  This
> single feature has ruled out the PIC on a number of projects I have
> worked on.

I know you were asked to compare AVR to the 18Fs, but I thought I should
point out that the 16-bit PICs have excellent bootloader support.

Vitaliy


2009\03\20@164742 by olin piclist

face picon face
Apparently Solarwind's way of getting around moderation is to send private
abuse message to individuals:


solarwind wrote:
{Quote hidden}

********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\03\20@170942 by Bob Blick

face
flavicon
face
Hi Olin,

I understand completely how you feel, however it is wrong to post
private messages to the Piclist.

The likeliest possible result is a flurry of off-topic messages with the
[PIC] tag.

What you should do is forward the message to piclist-ownerEraseMEspam.....mit.edu

Thanks for your cooperation.

-Bob


On Fri, 20 Mar 2009 15:49:18 -0500, "Olin Lathrop"
<EraseMEolin_piclistspamembedinc.com> said:

> private
> abuse message to individuals:

--
http://www.fastmail.fm - Or how I learned to stop worrying and
                         love email again

2009\03\20@171009 by cdb

flavicon
face
Hmm like a secret, private emails are just that - not public, 'cos if
they're public then they by definition are no longer private.

Now how have privacy rules been breached? :)

Colin
--
cdb, RemoveMEcolinEraseMEspamEraseMEbtech-online.co.uk on 21/03/2009

Web presence: http://www.btech-online.co.uk  

Hosted by:  http://www.1and1.co.uk/?k_id=7988359







2009\03\20@201317 by Peter

picon face
cdb <colin <at> btech-online.co.uk> writes:
> Hmm like a secret, private emails are just that - not public, 'cos if
> they're public then they by definition are no longer private.

I am with Olin on this one. Only direct correspondence between lawyers and
their paying, contract-bound clients, banks and their clients or a patient and
a doctor has any reasonable expectation of privacy, and in all those cases the
privacy requirement is based on an understanding that is independent from the
email medium (and also applies to phone, fax, radio, and snail mail
communication).

No part of an email obliges the recipient to keep the received email private.
Only contracts and understandings external to the email communication can do
that. People who expect to send unprintable dirt (including spam) by email and
have the recipient keep it or their ip's or originating servers private or not
use it against them are delusional.

Organizations and people who put trailers
in email to the effect that 'the communication is private and destined only to
the recipient' are particularly delusional (this occurs often when someone
sends 'private' email from an organization and cannot set the headers and
.sig). This counts at least twice over for anyone using a public email service
such as yahoo, gmail etc., since the clicked on contract already removes all
reasonable expectations of privacy (by machine or human inspection likewise).

Even without this, all transit hosts are expected to inspect headers,
attachments and contents, and drop or mark as spam anything they like. Email
is not snail mail with 'inviolability of mail' guaranteed by the postal
services (this notion is somewhat flawed in itself in these terrorist-infested
times).

Be polite at all times, or get smeared with your own excreta in the most
unexpected places. Sounds fair to me.

Peter


2009\03\20@221324 by Alden Hart

flavicon
face
IMHO a key element in the Arduino success is the aftermarket in
daughterboards - "shields" in the parlance. The openness is key to this
happening. Also, anyone can make and sell an Arduino knockoff mainboard,
and plenty do. This leads to many Arduino-based projects, new languages
- such as Processing, and new converts at every layer of the stack;
albeit one at a time - not the billions sold to Ford or GM.

So there's an entire stack being built out by multiple players. It may
be possible to PIC the lower layers, but I think the much more
interesting game at this point is to go full ARM core. Constructing some
kind of forwards compatibility at various layers of the interface would
be key if you wanted to bring the "layer players" community along.

(Opinions worth every penny you paid.)

Alden



DVD wrote:
{Quote hidden}

2009\03\21@001817 by William \Chops\ Westfield

face picon face

On Mar 20, 2009, at 7:13 PM, Alden Hart wrote:

> This leads to many Arduino-based projects, new languages
> - such as Processing, and new converts at every layer of the stack;
> albeit one at a time - not the billions sold to Ford or GM.

Um, the geneology goes the other way; "Processing" was first, as a  
desktop programming environment for non-programmers.  "Wiring" was the  
first microcontroller-based version, based on Processing, but the  
hardware never took off.  "Arudino" is a smaller cheaper (and more  
open) Wiring.

BillW

2009\03\21@015856 by Roger, in Bangkok

face
flavicon
face
Might be more beneficial to find email addresses for mom & dad ... maybe
even student advisers.  All people who (should!) appreciate such extra
behavioral inputs regarding their young charge:-))

That's also a good way to offer the occasional kudos that are/may indeed be
justly deserved.  I expect that he'll indeed turn out quite alright as an
adult, even if it takes an occasional plow-cleaning along the roughly hoed
row ...

RiB


On Sat, Mar 21, 2009 at 3:49 AM, Olin Lathrop <RemoveMEolin_piclistspam_OUTspamKILLspamembedinc.com>wrote:

{Quote hidden}

> -

2009\03\21@075926 by Russell McMahon

face
flavicon
face
>> Hmm like a secret, private emails are just that - not public, 'cos if
>> they're public then they by definition are no longer private.

> I am with  ...

DO NOT post on this unrelated topic under the [PIC] tag.

If you must post on it at all do so in OT.

Please.


And note that the discussion of the contents of the post that triggered this
has (quite rightly) been ruled disallowed by Bob B. (As opposed to
discussion of privacy issues per se which may just possibly have a place in
OT).

If somebody is / rude / silly / incapable / other disparaging terms /enough
to abuse you offlist then deal with it offlist. If you feel incapable of
dealing with such people directly and/or feel the need to have you hand held
by PICList admins then contact them by their group address
(EraseMEpiclist-ownerspamspamspamBeGonemit.edu)

Posting material onlist that would not be acceptable if someone else posted
it makes you as liable for the consequences as the originator - especially
so if posting it to the list is intended to cause a 'row' that you hope will
disadvantage the originator (or if that appears to be what you are trying to
achieve :-) ).


  Russell

2009\03\21@103233 by olin piclist

face picon face
Roger, in Bangkok wrote:
> Might be more beneficial to find email addresses for mom & dad ...
> maybe
> even student advisers.  All people who (should!) appreciate such extra
> behavioral inputs regarding their young charge:-))

Maybe he should only be allowed on the list after supplying verifiable
contact information for a parent or teacher.  I bet he'd be a lot more civil
if he didn't think he could get away with being anonymous.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\03\21@105734 by Tamas Rudnai

face picon face
On Sat, Mar 21, 2009 at 11:53 AM, Russell McMahon
<RemoveMEapptechKILLspamspamparadise.net.nz>wrote:

>
> If somebody is / rude / silly / incapable / other disparaging terms /enough
> to abuse you offlist then deal with it offlist. If you feel incapable of
> dealing with such people directly and/or feel the need to have you hand
> held
> by PICList admins then contact them by their group address
> (piclist-ownerSTOPspamspamspam_OUTmit.edu)


Is there any way to disable showing the poster's mail address so that such
an incident can be avoided?

Thanks,
Tamas
--
http://www.mcuhobby.com

2009\03\21@114920 by Isaac Bavaresco

flavicon
face

--- Em sex, 20/3/09, peter green <spamBeGoneplugwashSTOPspamspamEraseMEp10link.net> escreveu:


> Firstly while C18 is kinda C it is somewhat quirky. For
> example it does
> not have sensible handling of the >> operator for
> negative numbers
> (there are workarrounds for this but they require great
> care), it lacks
> a unified pointer type meaning a lot of routines end up
> with two copies

Some routines may have up to four versions (strcmp for instance).

I solved this by creating a "generic pointer" using some macros. Not perfect but works OK. I can even cross compile my PIC code by creating "do-nothing" versions of the macros for other platforms.

The macros and example are available at <http://www.piclist.com/techref/member/IMB-yahoo-J86/generic_pointers.htm>.

Regards,

Isaac



     Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com

2009\03\22@231059 by Peter

picon face
peter green <plugwash <at> p10link.net> writes:
> Firstly while C18 is kinda C it is somewhat quirky. For example it does
> not have sensible handling of the >> operator for negative numbers

?! what do you expect << with negative arguments to do ? << is defined only for
positive or unsigned integers, try it with a calculator and see what happens. I
tried it with two and the results are as expected 'strange'. << casts its
operand to an unsigned before the operation ... this can lead to 'unexpected'
results for whomever expects a float, a long or a signed integer to be handled
'gracefully' by  <<. F.ex -5 << 1 is 4.294967286e+9 ... and it's correct for 32
bit math (check the binary representation - hint: 2^32 == 4.294967296e+9). Oh,
and, in case you are wondering, -5 >> 1 is 2.147483645e+9, again, as expected P)
. For signed integer interpretation shifting does .not. imply sign extended
shifting, i.e. the sign will disappear and become a large positive number. This
is the normal way << and >> are expected to work.

Peter


2009\03\22@232554 by peter green

flavicon
face

> For signed integer interpretation shifting does .not. imply sign extended
> shifting, i.e. the sign will disappear and become a large positive number. This
> is the normal way << and >> are expected to work.
>  
The C standard leaves it as implementation defined whether to sign
extend or not, gcc sign extends and I consider this to be the sensible
behaviour. C18 doesn't sign extend.


2009\03\23@054128 by Peter P.

picon face
part 1 529 bytes content-type:text/plain; charset=us-asciiSorry for breaking the thread, email trouble.
Peter Green wrote:
>The C standard leaves it as implementation defined whether to sign
>extend or not, gcc sign extends and I consider this to be the sensible
>behaviour. C18 doesn't sign extend.And I say: You are right, gcc sign extends on >> and <<, wrongly. According to gcc -1 >> 1 is -1 (er .. eww). Test code attached. You see it is .not. enough to sign extend to get this right, you need to fix the 2's complement thing too (and add 1).



     

part 2 599 bytes content-type:application/x-bzip; name="gccsign.tar.bz2" (decode)

part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2009\03\23@062427 by Peter

picon face
Adding the line:

CFLAGS= -dP -dA -S

to the makefile and interpreting gccsign as gccsign.s (assembly output from the
compiler), one can see what is going on (I did not know that gcc uses LISP
internally for optimization -- hehe that makes sense). Of course gcc optimized
the integer operations away and used direct constants in the printf arguments
... but by using variables a=-1 b=1 and then in printf a >> b, one can see that
the compiler uses the assembly instruction sarl to shift arithmetically right.

Wonderful stuff when shifting a binary value that may be represented in an
integer register right, so one can mask out a lsb bit using & 1. Of course one
would never see it if the counter would count bits independently from the
register contents. On the other hand, if waiting for a zeroed register to exit
the loop ... Truly a millenium (21st) bug. Thanks for pointing this out, it was
worth investigating.

Peter


2009\03\23@194441 by Peter

picon face
So, isn't anyone worried about gcc doing: 0xFFFFFFFF >> 1 = 0xFFFFFFFF ?! gcc
for intel target implements this using the 'sar' instruction, which defines it
as 'divide by two'. What am I missing ? E.g.:

main() {
 int a=-1, b=1;
 printf( "hmm ? -1 >> 1 = %d (0x%08X)\n", a >> b );
}

prints -1 ?! MUST the ints be longs for it to work as expected ? I think that
the result of >> is incorrect for all negative 'a', the correct result is
obtained by substracting 1. No ?

Peter


2009\03\23@202309 by Tamas Rudnai

face picon face
Try with this test program and see the difference...

#include <stdio.h>

void main ()
{
   int a = 0xFFFFFFFF;
   unsigned b = 0xFFFFFFFF;

   a >>= 1;
   b >>= 1;

   printf ("%i, %08X,   %i, %08X\n", a, a, b, b );
}

Tamas


On Mon, Mar 23, 2009 at 11:44 PM, Peter <KILLspamplpeter2006spamBeGonespamyahoo.com> wrote:

{Quote hidden}

> -

2009\03\23@202536 by Vitaliy

flavicon
face
Peter wrote:
> So, isn't anyone worried about gcc doing: 0xFFFFFFFF >> 1 = 0xFFFFFFFF ?!
> gcc
> for intel target implements this using the 'sar' instruction, which
> defines it
> as 'divide by two'. What am I missing ? E.g.:
>
> main() {
>  int a=-1, b=1;
>  printf( "hmm ? -1 >> 1 = %d (0x%08X)\n", a >> b );
> }
>
> prints -1 ?! MUST the ints be longs for it to work as expected ? I think
> that
> the result of >> is incorrect for all negative 'a', the correct result is
> obtained by substracting 1. No ?
>

I wasn't following the conversation very closely, can you explain what
you're talking about? What does this have to do with PICduino?


2009\03\23@234538 by Peter

picon face
Vitaliy <spam <at> maksimov.org> writes:
> I wasn't following the conversation very closely, can you explain what
> you're talking about? What does this have to do with PICduino?

gcc does indeed do sign extended right shift of negative integers, with
horrible results as Peter Green suggested. picduino uses gcc afaik and P. G.
implemented another type of >> for pic32 (?)which behaves differently from the
gcc normal broken >>.

According to gcc -1 >> 1 = -1 which is a little bit sick. gcc uses the sar
instruction to do the shifting (I looked at the assembly output). Also
-5 >> 1 = -3 (should be -2). One would expect the >> to shift bits, without
sign extension, and in any case without getting stuck on 0xFFFFFFFF (== -1)
and I did in fact rely on txd_bit = acc & 1; acc = acc >> 1; many a time (but
with a bit counter). Apparently this is not such a good idea when not using a
bit counter (using a stop bit in the register and waiting for it to be shifted
out).

To correctly divide by two a negative number using >> it should sign extended
right shift, then add 1 (because it's 2's complement iff the msb is 1 (sign)),
but this breaks the desired meaning of >> which is to bit shift to the right.
gcc does not do that (gcc for x86), it is broken imho. I would expect >> to
*always* take the lhs argument as an unsigned integer and shift it right, and
*not* sign extend it.

In fact the optimizer should deal with x / 2^N and turn it
into shr ax, cl; followed by inc ax; iff ax.31 == 1, which is the correct way
to do x /= 2^N;, and programmers should never use >> N to divide by 2^N. Imho
programmers should never rely on >> for division of negative numbers, and >>
should not do sign extension (it is presumed to do shifting only). E.g. think
of >> used to shift a bit pattern to make, say, a running light row or control
the phases of a stepper.

It is interesting that C does not have a circular bit buffer rotation
operator, like rol or ror, which could be implemented using >>> or <<<
to encode it f.ex. maybe the machines on which D&R implemented C did not have
a rotation instruction.

 Peter


2009\03\24@022822 by William \Chops\ Westfield

face picon face

On Mar 23, 2009, at 4:44 PM, Peter wrote:

> isn't anyone worried about gcc doing: 0xFFFFFFFF >> 1 = 0xFFFFFFFF ??

I dunno.  It looks correct to me.  Or at least arguable as correct if  
you think that ">>" means "shift", rather than "divide by 2^n".   I  
can't see that "0xFFFFFFFF >> 1 == 0" is any more sensible.  I'd  
expect either 0xFFFFFFFF or 0x7FFFFFFF; perhaps I just have poor  
expectations for negative signed numbers being shifted (it never did  
seem worth having a separate instruction for?)

If an architecture HAS a separate Arithmatic Shift instruction, I  
CERTAINLY expect the C compiler for that architecture to use that  
instruction for a signed shift...  Especially given C's sometimes-
status as a "High level assembler."

If you want x/2^n, then that's what you should write, and then (if  
appropriate) you can complain about the compiler not optimizing it to  
(x>>1) + 1

BillW

2009\03\24@022928 by Wouter van Ooijen

face picon face
> gcc does indeed do sign extended right shift of negative integers, with
> horrible results as Peter Green suggested. picduino uses gcc afaik and P. G.
> implemented another type of >> for pic32 (?)which behaves differently from the
> gcc normal broken >>.

You are using 'broken' and 'should' in a very sloppy way. GCC should
behave conform the C standard that it claims to implement. If it doesn't
it is indeed broken. If it does, but you don't like it, then you
disagree with the standard. Not GCC's fault.

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2009\03\24@044609 by Tamas Rudnai

face picon face
On Tue, Mar 24, 2009 at 3:45 AM, Peter <EraseMEplpeter2006spamEraseMEyahoo.com> wrote:

> According to gcc -1 >> 1 = -1 which is a little bit sick. gcc uses the sar
> instruction to do the shifting (I looked at the assembly output). Also
> -5 >> 1 = -3 (should be -2). One would expect the >> to shift bits, without
> sign extension, and in any case without getting stuck on 0xFFFFFFFF (== -1)
> and I did in fact rely on txd_bit = acc & 1; acc = acc >> 1; many a time
> (but
> with a bit counter). Apparently this is not such a good idea when not using
> a
> bit counter (using a stop bit in the register and waiting for it to be
> shifted
> out).
>

Just think it over what would happen if C was using normal shift:

-5 is 0xFB   >>1  will be then 0x7D which is 125 decimal...

Tamas
--
http://www.mcuhobby.com

2009\03\24@073307 by Michael Rigby-Jones

picon face


> -----Original Message-----
> From: @spam@piclist-bounces@spam@spamspam_OUTmit.edu [spamBeGonepiclist-bouncesspamKILLspammit.edu] On
Behalf
> Of Peter
> Sent: 23 March 2009 23:44
> To: .....piclistspam_OUTspammit.edu
> Subject: Re: [PIC] Why let the atmel guys have all the fun? - PICduino
-
>
> So, isn't anyone worried about gcc doing: 0xFFFFFFFF >> 1 = 0xFFFFFFFF
?!
{Quote hidden}

think
> that
> the result of >> is incorrect for all negative 'a', the correct result
is
> obtained by substracting 1. No ?
>
> Peter

This is exactly the behaviour expected when you right shift a signed
integer and the compiler sign extends.  Since the results of right
shifting a signed integer are implementation defined, GCC's behaviour is
perfectly correct, and IMO the only sensible way to do things, since the
alternative causes a negative number to change sign.

This does show that shifting signed integers is generally to be avoided
if you want to create portable code.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2009\03\24@081750 by olin piclist

face picon face
Peter wrote:
> gcc does indeed do sign extended right shift of negative integers, with
> horrible results

Actually, doing a arithmetic shift on signed numbers and a logical shift on
unsigned sounds like the single most reasonable way to implement the C >>
operator on machines where arithmetic and logical shifts have the same cost.
This is also totally consistant with the C standard, so the results should
be neither horrible nor unexpected.

> According to gcc -1 >> 1 = -1 which is a little bit sick.

No, it is the most reasonable outcome and totally within the standard.  If
there is anything stupid going on here, it's someone writing C code not
expecting this as a possibility.

Let's say we're on a machine where these numbers are 16 bit integer for
simplicity.  Would you rather -1 >> 1 be 32767?  I think -1 makes more
sense, although both would actually be legal C.

> Also -5 >> 1 = -3 (should be -2).

You need to go look up bit shifts and the C standard.  -5 in binary is
..11011.  Shifting it right one bit yields ...11101, which is -3 if a
arithmetic right shift was used and 32765 if logical shift was used (again
using 16 bit words for simplicity).  I'd say -3 is rather more intuitive,
but no way should the answer be -2, which is a bit pattern of ...11110 and
would also violate the C standard (for good reason).

I don't like the way the C >> operator is defined, but in this case (-5 >>
1) being -3 is both correct and the most logical choice.

> One would expect the >> to shift
> bits, without sign extension,

Not if one had bothered to read the description of ">>".

> I would expect >> to *always* take the lhs argument as an unsigned
> integer and shift it right, and *not* sign extend it.

Wrong.  RTFM (where M is the C standard).


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\03\24@101857 by Bob Ammerman

picon face
> So, isn't anyone worried about gcc doing: 0xFFFFFFFF >> 1 = 0xFFFFFFFF ?!
> gcc
> for intel target implements this using the 'sar' instruction, which
> defines it
> as 'divide by two'. What am I missing ? E.g.:
>
> main() {
>  int a=-1, b=1;
>  printf( "hmm ? -1 >> 1 = %d (0x%08X)\n", a >> b );
> }
>
> prints -1 ?! MUST the ints be longs for it to work as expected ? I think
> that
> the result of >> is incorrect for all negative 'a', the correct result is
> obtained by substracting 1. No ?
>
> Peter

SAR is *not* 'divide by two'. It is "shift arithmetic right". That means
that the high order bit is duplicated when shifting right.

So, when you take a bunch of 1 bits (which is what -1 is):


111.....111

And shift in a one at the top:

1111.....11

You still have a bunch of 1's, which is still -1.

This is *not* in any way a bug.  It is the way arithmetic right shifts work.
They just can't be considered 'divide by two' for all values.

-- Bob Ammerman
RAm Systems

2009\03\24@103357 by Alan B. Pearce

face picon face
>To correctly divide by two a negative number using >> it should
>sign extended right shift, then add 1 (because it's 2's complement
>iff the msb is 1 (sign)),

Why ???

You have specifically required the compiler to generate a right shift of the
bits in a number (which happens to be a negative number, but could be a
positive number in the same variable).

It seems to me that you are expecting the C compiler to second guess what
the answer should be, which is not what the original C compilers expected it
to do - they expected the code writer to know what they are doing, and if
that person wants the result you are wanting, then suitable coding should be
put around the right shift, or perhaps a divide instruction would have been
a better instruction to use.

To me you are expecting something from the compiler which has never been
expected. Witness the recent discussion on C, where I believe the general
consensus was that 'you need to know what you are doing' to be able to use
C.

2009\03\24@121343 by John Coppens

flavicon
face
On Tue, 24 Mar 2009 07:29:19 +0100
Wouter van Ooijen <TakeThisOuTwouter.....spamTakeThisOuTvoti.nl> wrote:

> > gcc does indeed do sign extended right shift of negative integers,
> > with horrible results as Peter Green suggested. picduino uses gcc
> > afaik and P. G. implemented another type of >> for pic32 (?)which
> > behaves differently from the gcc normal broken >>.
>
> You are using 'broken' and 'should' in a very sloppy way. GCC should
> behave conform the C standard that it claims to implement. If it
> doesn't it is indeed broken. If it does, but you don't like it, then
> you disagree with the standard. Not GCC's fault.

It does comply:

"The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an
unsigned type or if E1 has a signed type and a nonnegative value, the
value of the result is the integral part of the quotient of E1 / 2E2 . If
E1 has a signed type and a negative value, the resulting value is
implementation-defined."

But I agree it doesn't _feel_ right. I would totally expect >> to behave
as a logical operation (which doesn't use negative numbers), and find it
incorrect to assume it would behave it as a math operation. I didn't
know, now that I read it I'll take care of avoiding >>'s in the future.

On the other hand, if a divide by 2^N is needed, I would write /2^N and
expect the compiler to select the right shift operation.

Which is another reason that >> should be logical (not math). And the
reason why Pascal has the 'div' operator. It all looked somewhat
incredible, so I ran the test in C, Pascal and some others:

C:          a: -16;  >> 1: -8;  /2: -8
Pascal:     a: -16; shr 1: 2147483640; div 2: -8
Tcl:        a: -16;  >> 1: -8;  /2: -8
PHP:            a: -16;  >> 1: -8;  /2: -8
MySQL:            (-16 >> 1): 9223372036854775800; (-16 / 2): -8
Javascript: a: -16;  >> 1: -8;  /2: -8

Note: I used -16 (not -1) to be able to do a /2.

2 languages treat >> as logical, 4 as math. Guess I won't be able to throw
those reference manuals away after all (and feel safe)

John

2009\03\24@122647 by John Coppens

flavicon
face
On Tue, 24 Mar 2009 13:13:38 -0300
John Coppens <TakeThisOuTjohnKILLspamspamspamjcoppens.com> wrote:

> so I ran the test in C, Pascal and some others:

Perl:                a = -16; a >> 1: 2147483640; a/2: -8

Tally: 3 languages as logical, 4 as math.

2009\03\24@125031 by Wouter van Ooijen

face picon face
> It does comply:
>
> "The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an
> unsigned type or if E1 has a signed type and a nonnegative value, the
> value of the result is the integral part of the quotient of E1 / 2E2 . If
> E1 has a signed type and a negative value, the resulting value is
> implementation-defined."
>
> But I agree it doesn't _feel_ right.

I can have some sympathy with that, but that should be a gripe with the
C standard, not with GCC.

I like portability. Hence I would prefer a compiler, for *all*
implementation-dependent features, to do something that draws my
attention. (Like ordering a pizza, preferrably 4 cheeses.)

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2009\03\24@131435 by Wouter van Ooijen

face picon face
>> so I ran the test in C, Pascal and some others:
>
> Perl:                a = -16; a >> 1: 2147483640; a/2: -8
>
> Tally: 3 languages as logical, 4 as math.

Are you sure you are tallying languages (as opposed to implementations!)?

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2009\03\24@134757 by John Coppens

flavicon
face
On Tue, 24 Mar 2009 17:40:38 +0100
Wouter van Ooijen <.....wouterspamRemoveMEvoti.nl> wrote:

> the resulting value is
> > implementation-defined."
> >
> > But I agree it doesn't _feel_ right.
>
> I can have some sympathy with that, but that should be a gripe with the
> C standard, not with GCC.

A standard shouldn't say 'implementation-defined' (except maybe with
non-standard-language extensions. Which >> isn't). That isn't a standard,
but is trying to be politically correct. So, yes, in this case I don't
agree with the standard.

> I like portability. Hence I would prefer a compiler, for *all*
> implementation-dependent features, to do something that draws my
> attention. (Like ordering a pizza, preferrably 4 cheeses.)

and I agree on the 4 cheese-pizza too... It would undoubtedly increase
the popularity of the picduino.

John

2009\03\24@144344 by Vitaliy

flavicon
face
John Coppens wrote:
>> the resulting value is
>> > implementation-defined."
>> >
>> > But I agree it doesn't _feel_ right.
>>
>> I can have some sympathy with that, but that should be a gripe with the
>> C standard, not with GCC.
>
> A standard shouldn't say 'implementation-defined' (except maybe with
> non-standard-language extensions. Which >> isn't). That isn't a standard,
> but is trying to be politically correct. So, yes, in this case I don't
> agree with the standard.

Under what circumstances would you want to >> a negative number, anyway?

Vitaliy

2009\03\24@145641 by Michael Rigby-Jones

picon face


> -----Original Message-----
> From: RemoveMEpiclist-bouncesspamspamBeGonemit.edu [spamBeGonepiclist-bounces@spam@spamspam_OUTmit.edu] On
Behalf
{Quote hidden}

the
> >> C standard, not with GCC.
> >
> > A standard shouldn't say 'implementation-defined' (except maybe with
> > non-standard-language extensions. Which >> isn't). That isn't a
standard,
> > but is trying to be politically correct. So, yes, in this case I
don't
> > agree with the standard.
>
> Under what circumstances would you want to >> a negative number,
anyway?
>
> Vitaliy

It can be handy if you are trying to shave cycles of integer math
operations, as long as you understand the consequences.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2009\03\24@150507 by Wouter van Ooijen

face picon face
> A standard shouldn't say 'implementation-defined'

That is an opinion. It leads to a language design that is better
defined, but will likely produce slower executables on at least some
hardware. Which leads to the manufacturers of such hardware not adopting
that language, which leads to users not using it.

C is a complex compromise. Without some of its properties that we can
now see as defects it would not be in widespread use today.

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2009\03\24@171345 by Vitaliy

flavicon
face
Michael Rigby-Jones wrote:
>> Under what circumstances would you want to >> a negative number,
> anyway?
>
> It can be handy if you are trying to shave cycles of integer math
> operations, as long as you understand the consequences.

Can you provide an example?

Vitaliy

2009\03\24@173254 by Vitaliy

flavicon
face
Wouter van Ooijen wrote:
>> A standard shouldn't say 'implementation-defined'
>
> That is an opinion. It leads to a language design that is better
> defined, but will likely produce slower executables on at least some
> hardware. Which leads to the manufacturers of such hardware not adopting
> that language, which leads to users not using it.
>
> C is a complex compromise. Without some of its properties that we can
> now see as defects it would not be in widespread use today.

Being able to express binary numbers as '0b1010' comes to mind, as well as
compromises on the library level (printf that doesn't support all the bells
and whistles, etc).

Vitaliy


2009\03\24@180511 by William \Chops\ Westfield

face picon face
> A standard shouldn't say 'implementation-defined'
>
I'm inclined to be a bit frustrated when I run into "implementation  
defined" in such vague terms on such a common operation.  The standard  
ought to at least list possible choices (I'm inclined to believe that  
"/2" is NOT one of the valid choices, and that -1>>1 should NEVER  
equal zero.  So that leaves "shift in 0" (treat as unsigned) or "shift  
in sign bit" as possibilities.  The spec could say that.  It could  
even offer guidance along the lines of "if the target cpu has an  
arithmetic shift instruction, that's what should be used."

Optimizing divide ...   A single position shift of an 8-bit byte isn't  
the greatest thing in the world once you get into multi-bit shifts of  
multi-byte words.  I saw a complaint recently that the AVR gcc  
compiler DID use shifts, when "using the built-in multiplier would  
take fewer cycles" (assuming that the operands were in the right  
registers for use of the the special-case multiply instruction, of  
course.)

And of course a lot of this is just a result of the "bad habit" of  
using "int" as the general purpose data type even in situations where  
"unsigned int" is more correct.
Although I'm also annoyed that "for (int i = 0; i < sizeof(mystruct); i
++)" generates a warning from the fussier compilers these days...

BillW

2009\03\25@065402 by Michael Rigby-Jones

picon face


> -----Original Message-----
> From: TakeThisOuTpiclist-bouncesspamspammit.edu [piclist-bouncesEraseMEspammit.edu] On
Behalf
{Quote hidden}

The following is a trivial example, showing a fractional multiply on a
signed integer, using a (quite old) HiTech PICC compiler (8.05PL2),
compiled for a 16F877.

#include <pic.h>

volatile signed int foo, bar;

/* Integer multiply by 0.171875 */
void main ( void ) {
       
       for(;;) {

               NOP();

               foo = -23456;
       
               foo >>= 3;
               bar = foo;
               foo >>= 2;
               bar += foo;
               foo >>= 1;
               bar += foo;
               
               /* This always takes 41 cycles, no stack */
               NOP();

               foo = -23456;
       
               foo /= 8;
               bar = foo;
               foo /= 4;
               bar += foo;
               foo /= 2;
               bar += foo;
               
               /* This takes approx 1100 to 1300 cycles + one stack
level */
               NOP();
       }


}


With unsigned int's there is virtually no difference between shifting
and dividing, but with signed int's this version of the compiler uses
the integer division library function so adds considerable overhead.  Of
course a different compiler (or a newer HiTech one) may perform
considerably better here, but the point is that shifting signed integers
is a useful option in this case.

Due to the rounding toward -1 that occurs with the shifts (the PICC
compiler sign extends) the result becomes more inaccurate when the
number of bits in the dividend is less then the total number of shifts,
but this is often an acceptable compromise IME.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2009\03\25@074729 by Tamas Rudnai

face picon face
Hat about to make a macro like this:

#define SHR(k,n) ( k<0 ? ~( (~k+1) >> n )+1 : k >> n )

so then

              foo = -23456;

              foo = SHR(foo,3);
              bar = foo;
              foo = SHR(foo,2);
              bar += foo;
              foo = SHR(foo,1);
              bar += foo;

should take less cycles - but I have not tried yet will try in the evening.

Tamas


On Wed, Mar 25, 2009 at 10:53 AM, Michael Rigby-Jones <
RemoveMEMichael.Rigby-JonesEraseMEspamspam_OUTbookham.com> wrote:

{Quote hidden}

--
http://www.mcuhobby.com

2009\03\25@092950 by Michael Rigby-Jones

picon face


> -----Original Message-----
> From: @spam@piclist-bouncesRemoveMEspamEraseMEmit.edu [EraseMEpiclist-bouncesspam@spam@mit.edu] On
Behalf
{Quote hidden}

evening.
>
> Tamas

Hi Tamas,

I just tried it with the same compiler and I get 81 cycles for positive
values, 114 for negative values.  Still a very good saving over the
divide library functions in this case.

In this example it would make more sense to test for a negative value
before all the shifts, compliment and then re-compliment afterwards.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2009\03\25@095446 by Bob Ammerman

picon face
>>
>> Hat about to make a macro like this:
>>
>> #define SHR(k,n) ( k<0 ? ~( (~k+1) >> n )+1 : k >> n )
>>

is this any faster??

#define SHR(k,n) ( k<0 ? -(-k >> n) : k>>n )

btw: assuming two's complement notation and 16-bit integers, this breaks for
0x8000 (ie -32768), unless we do the following:

; assumption: k is type 'int'

#define SHR(k,n) ( k<0 ? (int) - ( (unsigned int) -k >> n) : k >> n )


-- Bob Ammerman
RAm Systems

2009\03\25@113721 by Peter

picon face
John Coppens <john <at> jcoppens.com> writes:
> Tally: 3 languages as logical, 4 as math.

Imnsho, run your tests again, with -1 being shifted. The problems occur most
often in boundary cases. -1 is a boundary case.

Peter




2009\03\25@121219 by Peter

picon face
William "Chops" Westfield <westfw <at> mac.com> writes:
> Although I'm also annoyed that "for (int i = 0; i < sizeof(mystruct); i
> ++)" generates a warning from the fussier compilers these days...

I'd rephrase that along the lines of 'what bad stuff were they smoking in the
1980s when they decided to standardize sizet_t as int, thus ensuring that a) it
will be possible to have negative sized objects and b) any allocated object will
be measurable to at most one half of the available address space' (if
sizeof(void*) == sizeof(unsigned), true for a very long time before 32 bits
became common on the desktop ).

This was already an incorrect assumption on 8 bit machines in contemporary
(1980s) CP/M times: sizeof(unsigned)=16; thus MAXINT=2^15; and so is sizeof()
output, but sizeof(ram)=often >48k, so one could not simply malloc() something
larger than 32k-1).

Rhymes with "640k will be enough for anyone for a long time", and "why not use
int as return type for time(), nobody will be using this by 2038 anyway"
(current include files on 32 bit os's define time_t as long int - we still have
hopes to achieve time travel, then). Oh, and difftime((time_t)now,(time_t)then)
returns of type (double) (not long unsigned or time_t, god forbid these be
compatible and ease the programmer's life), and also removes the last doubt
about the need for a signed time_t to support difftime() when it needs to return
a negative difference.

Riight, planned obsolescence, eh ?! Must be the same type of "spreadsheet based
numerical darkvoyance/divining rod/cracked crystal ball/soviet economy style 5
year planning" that has sent the economy into the cords now. In general,
industry based committees have the type of care and concern for the future
previously seen in locusts and in politicians, imho.

Anyway, C is a hack on portable assembly, and it had *no* types initially, so
just live with the problems, and be grateful for the benefits.

Peter


2009\03\25@123501 by Peter

picon face
Bob Ammerman <rammerman <at> verizon.net> writes:
> This is *not* in any way a bug.  It is the way arithmetic right shifts work.
> They just can't be considered 'divide by two' for all values.

I believe that a right shift of a negative number implemented as is by gcc is
'surprising' and does not follow the principle of 'least surprise'. It is enough
to mistakenly define a register that is to be used to shift out (or in) data as
int not unsigned, to get data corruption, with no compiler warning. If the data
consumer is a piece of hardware, smoke let-out could be the result, perhaps
later, when an unexpected bit pattern that can be interpreted as a negative
number will be loaded and shifted. That is not good. of course it is a
'programmer error', but ... In any case, anyone reading the description of '>>'
as 'shift (*not* arithmetically shift) the lhs operand right by the number of
bit positions specified by the rhs operand' would be very surprized at what >>
does with a binary bit pattern that may be a negative operand when interpreted
as a number, perhaps assuming that the lhs argument could be declared an int as
many other things can be.

Peter


2009\03\25@130644 by olin piclist

face picon face
Peter wrote:
> Imnsho, run your tests again, with -1 being shifted. The problems
> occur most often in boundary cases. -1 is a boundary case.

This is math, not voodoo.

All implementations we have seen so far do either a logical or arithmetic
shift.  The choice of these will be immediately apparent with any negative
number.  Arithmetic will preserve the sign bit and logical will not.  For
arthmetic, negative number will be roughly half their original value.  For
logical you will get a positive number.  This will work whether you put
in -1, -3, or -107.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\03\25@132639 by olin piclist

face picon face
Peter wrote:
> I believe that a right shift of a negative number implemented as is
> by gcc is 'surprising' and does not follow the principle of 'least
> surprise'.

Not to anyone that understands what a shift is.

Just because you are clinging to some delusion what >> on a signed integer
is supposed to mean doesn't make the compiler wrong.  The standard clearly
says anything goes.  I think that was a stupid choice, but it's even more
stupid to use >> on a signed integer since there is no guarantee what it
might do.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\03\25@142754 by Peter

picon face
Olin Lathrop <olin_piclist <at> embedinc.com> writes:
> This is math, not voodoo.

Look, if someone makes cars whose steering wheels work backwards when the driver
weighs more than 100kg it had better be posted up front, and not be buried in a
350 page standard that must be ordered by mail. I agree that the operator is
implemented with the best of intentions according to the standard. I also think
that -1 >> 1 == -1 is bordering on vodoo. The word arithmetic as in
'*arithmetic* right shift' does not appear anywhere in the C specifications wrt.
'>>'. The Wikipedia article on this explicitly specifies that C99 does *not*
(!!) specify the exact behavior in this case. Guessing what is best in this case
by compiler implementors has led to this discussion in the first place!

http://en.wikipedia.org/wiki/Arithmetic_shift
(search for 'c language' for quick access)

Peter


2009\03\25@144207 by Peter

picon face
My final addition to this is a historical view on the issue, from Brian
Kernighan himself (the vintage of the machines referred to dates the text):

http://www.lysator.liu.se/c/bwk-tutor.html

see at '>>      right shift     (arithmetic on PDP-11;  logical on H6070,
IBM360)'

brilliant as far as 'standards' go, anyway, it is clear that the implementors
choose the implementation that encodes to the shortest and most appropriate (in
that order) assembly code if possible.

Peter


2009\03\25@151506 by Bob Blick

face
flavicon
face
On Wed, 25 Mar 2009 18:27:37 +0000 (UTC), "Peter"
<@spam@plpeter2006spam_OUTspam.....yahoo.com> said:
> I also
> think
> that -1 >> 1 == -1 is bordering on vodoo. The word arithmetic as in
> '*arithmetic* right shift' does not appear anywhere in the C
> specifications wrt.
> '>>'. The Wikipedia article on this explicitly specifies that C99 does
> *not*
> (!!) specify the exact behavior in this case. Guessing what is best in
> this case
> by compiler implementors has led to this discussion in the first place!

Yes, exactly!

In C I never use shift on a signed number. If I need to shift in order
to bit-bang or something, I'll use the unsigned element in a union.

Even in Pascal, where it tries to protect you from type mismatches even
when you know what you want, I make a union, as in:

type
 bbunion = record
   case byte of
     0: (s: smallint);
     1: (u: word);
     2: (b0: byte;
         b1: byte);
 end;

It's just safer that way(although endianness is yet another pitfall that
this does not address).

Cheerful regards,

Bob

--
http://www.fastmail.fm - Same, same, but different...

2009\03\25@160011 by olin piclist

face picon face
Peter wrote:
> I also think that -1 >> 1 == -1 is bordering on vodoo.

It seems perfectly logical to me.  In fact, I'd say it is the preferred
behavior given the options.

> The Wikipedia article on this explicitly specifies that C99 does
> *not* (!!) specify the exact behavior in this case.

Exactly.  So you should be neither surprised nor have a right to complain
just because it didn't do whatever you thought it would.  You had a bug and
your code broke.  Don't try to blame your mistake on everyone else.  No
amount of hopping about is going to save face.  It's actually making it
worse by re-emphasizing your screwup.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\03\25@160209 by olin piclist

face picon face
Bob Blick wrote:
> In C I never use shift on a signed number. If I need to shift in order
> to bit-bang or something, I'll use the unsigned element in a union.
>
> Even in Pascal, where it tries to protect you from type mismatches
> even when you know what you want, I make a union, as in:
>
> type
>   bbunion = record
>     case byte of
>       0: (s: smallint);
>       1: (u: word);
>       2: (b0: byte;
>           b1: byte);
>   end;
>
> It's just safer that way(although endianness is yet another pitfall
> that this does not address).

Which is why a cast is probably better in this case if you want to shift the
bits around in a signed integer.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\03\25@162136 by Michael Rigby-Jones

picon face


> -----Original Message-----
> From: spamBeGonepiclist-bouncesEraseMEspammit.edu [piclist-bouncesspamBeGonespammit.edu] On
Behalf
> Of Peter
> Sent: 25 March 2009 18:28
> To: RemoveMEpiclist@spam@spamspamBeGonemit.edu
> Subject: Re: [PIC] Why let the atmel guys have all the fun? - PICduino
-
>
> Olin Lathrop <olin_piclist <at> embedinc.com> writes:
> > This is math, not voodoo.
>
> Look, if someone makes cars whose steering wheels work backwards when
the
> driver
> weighs more than 100kg it had better be posted up front, and not be
buried
> in a
> 350 page standard that must be ordered by mail


To use your analogy, just because someone can drive a car, would you
also expect them to be able to jump into a Formula 1 car and drive it
perfectly without any tuition or learning curve?

When you start using a new programming tool (e.g. compiler), is your
preferred technique to just dive in, ignoring all documentation and
expect that your assumptions as to how it should work will always be
correct?  I'm all for a hands on approach to learning, but it's
unrealistic to expect experience gained from one system will always
apply to every other system.

> I also think that -1 >> 1 == -1 is bordering on vodoo.

But you believe that a right shift of a small negative value which turns
it into a large positive value is fine, and should be the expected
result?

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2009\03\26@022920 by Wouter van Ooijen

face picon face
> I believe that a right shift of a negative number implemented as is by gcc is
> 'surprising' and does not follow the principle of 'least surprise'.

I can partially agree with that , but the "principle of least surprise"
can not be applied without stating who the audience is. For *me* the
least surprise is when portability issues in my code give the weirdest
results possible. So a shift left of a negative number should order pizza.

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2009\03\26@023151 by Wouter van Ooijen

face picon face
> Look, if someone makes cars whose steering wheels work backwards when the driver
> weighs more than 100kg it had better be posted up front, and not be buried in a
> 350 page standard that must be ordered by mail.

Someone who drives a car has better get sufficient training first.

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2009\03\26@125647 by Vitaliy

flavicon
face
Wouter van Ooijen wrote:
>> I believe that a right shift of a negative number implemented as is by
>> gcc is
>> 'surprising' and does not follow the principle of 'least surprise'.
>
> I can partially agree with that , but the "principle of least surprise"
> can not be applied without stating who the audience is. For *me* the
> least surprise is when portability issues in my code give the weirdest
> results possible. So a shift left of a negative number should order pizza.

This doesn't make any sense. :)

I'm quite sure that Wouter would freak out if a pizza delivery guy knocked
on his door after he did a "shift left" on a negative number.

Vitaliy

2009\03\26@145923 by Wouter van Ooijen

face picon face
>> So a shift left of a negative number should order pizza.
>
> This doesn't make any sense. :)
>
> I'm quite sure that Wouter would freak out if a pizza delivery guy knocked
> on his door after he did a "shift left" on a negative number.

As I said, I expect it to order a four-cheese pizza. I would freak out
on any other pizza.

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2009\03\26@152749 by Joseph Bento

face
flavicon
face

On Mar 26, 2009, at 12:59 PM, Wouter van Ooijen wrote:

>>> So a shift left of a negative number should order pizza.
>>
>> This doesn't make any sense. :)
>>
>> I'm quite sure that Wouter would freak out if a pizza delivery guy  
>> knocked
>> on his door after he did a "shift left" on a negative number.
>
> As I said, I expect it to order a four-cheese pizza. I would freak out
> on any other pizza.

 Quattro Formaggi -  Yummmm.....

Lots of variations on the cheeses, but Fontina, Mozzarella, Parmesan,  
and goat cheese makes a fabulous pizza.

You're in the Netherlands - is Heineken a bit too gauche, or is it  
acceptable with your pizza?  :-)

Joe
 

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...