Do you see any future to the 8-bit MCU's?

On 07/22/2011 07:22 PM, KK6GM wrote:

> 1) 8-bit cores presumably are lower-power than corresponding 16-bit
> cores.
> 2) 8-bit code will require more instructions than 16-bit code when
> dealing with>8-bit values, including addresses.
> 3) Might it be the case that the disadvantage of (2) offsets the
> advantage of (1) in many cases, thus making 16-bits a sweet spot in
> extreme low power designs?
>
> It may be true or it may be false, but it is not _obviously_ false to
> me.

I think the gap between 8 bit and 32 bit is too small to leave anything 
but they tiniest niche inbetween.

Even if there was some profit in that, it is likely that both 8 bit and 
32 bit manufacturers would make improvements to keep competing with each 
other.

On 7/22/2011 10:22 AM, KK6GM wrote:

> I don't think you're following my question.  Let me try again.
> Remember, I was responding to a post about "extreme low power
> designs."
>
> 1) 8-bit cores presumably are lower-power than corresponding 16-bit
> cores.

For the most part, power follows devices*frequency.  So, if you
have half the active silicon running at twice the frequency
you are (roughly speaking) using equivalent power.
(neglecting other factors)

> 2) 8-bit code will require more instructions than 16-bit code when
> dealing with>8-bit values, including addresses.

Sure.  But, it need not require twice as much "work" to do the same
thing!

I.e., if you are processing single *bits* in a 128b wide address space
(i.e., *lots* of "bits") then the cost of manipulating the address goes
up but the cost of processing the *bit* goes down (smaller ALU).
How often you have to manipulate one or the other becomes a factor,
then.

E.g., if you can walk through 256 consecutive addresses before you
have to "bear extra cost" to handle the ">8 bit" address space,
then your address processing costs are rather small.

If you have to process addresses algorithmically (e.g., walking through
the address space as if it was an exponential curve), then your cost
for address processing goes way up!  OTOH, if you are loading those 
addresses from a table, then the cost of the "programmatic load" isn't
that much more than the "work" a wider processor would have to do to
load that address in "a single reference", etc.

> 3) Might it be the case that the disadvantage of (2) offsets the
> advantage of (1) in many cases, thus making 16-bits a sweet spot in
> extreme low power designs?

IMO, no.  The "data" (avoiding your choice of "real world data")
that many devices have to process is often very simple (e.g.,
"Is the current temperature greater than the setpoint temperature?")
and lacking in severe time constraints (i.e., you can afford *hundreds*
of clock cycles to process it, not just *one*!).

> It may be true or it may be false, but it is not _obviously_ false to
> me.

I look at it this way:  can I code the same application on a 16b
processor in *half* the code of an 8b?  (i.e., does each instruction
do twice as much work in a 16b).  IME, that hasn't been the case.
There's too much "little stuff" where the 16b yields no savings.

For *extreme* low power applications, you also have to look at the
startup costs of the processor (e.g., coming out of deep sleep).
I suspect it is more efficient to wake up, do "some stuff" and
then go back to sleep than it is to wake up, do *half* as much
stuff and then go back to sleep (assuming "some stuff" is a
small work effort)

On 7/22/2011 10:37 AM, Arlet Ottens wrote:
> On 07/22/2011 07:22 PM, KK6GM wrote:
>
>> 1) 8-bit cores presumably are lower-power than corresponding 16-bit
>> cores.
>> 2) 8-bit code will require more instructions than 16-bit code when
>> dealing with>8-bit values, including addresses.
>> 3) Might it be the case that the disadvantage of (2) offsets the
>> advantage of (1) in many cases, thus making 16-bits a sweet spot in
>> extreme low power designs?
>>
>> It may be true or it may be false, but it is not _obviously_ false to
>> me.
>
> I think the gap between 8 bit and 32 bit is too small to leave anything
> but they tiniest niche inbetween.

Exactly.  You can shrink the die and increase the clock to
make up the difference.

*Or*, put extra hardware on the die to eliminate the "expensive"
application aspects that might otherwise suggest the need for
a more "capable" processor (e.g., communication subsystems).

Its a shame some of the older CPU designs have fallen by the wayside
as they would easily lend themselves to multicore designs with
infinitesimal cost penalties (besides the real estate for the second
core) -- you can do a *lot* with a tightly coupled second CPU!

I find many applications just need lots of address space but not
much computational horsepower.  And, since you aren't going to
"halve" that address space by moving to a wider core, you don't
usually get as "efficient" a solution as you move up in CPU
complexity (though market pressures can distort *pricing*
sweet spots)

> Even if there was some profit in that, it is likely that both 8 bit and
> 32 bit manufacturers would make improvements to keep competing with each
> other.

Exactly.

People have been predicting the demise of "tape" technology for
decades.  Disks keep getting faster, smaller, cheaper, etc.

But, gee, the same sorts of things keep happening to *tape*  :-/

(no, I don't believe this will continue...)

On 22.07.2011 14:22, Rich Webb wrote:
> On Fri, 22 Jul 2011 10:54:24 +0200, Tilmann Reh
> <usenet2007nospam@autometer.de>  wrote:
>
>> Dave,
>>
>> maybe you aren't aware of it, but you are starting a new thread
>> everytime you post an answer.
>
> That may depend on the news reader or, possibly, on the Usenet server
> one is using.

No, it doesn't.  The problem is entirely and exclusively with posts 
originating at Google Groups, and the problem is that their posts lack 
the References: header.  Yes, some news clients can be told to ignore 
broken References and construct threads based on Subject similarity. 
But that's just wrong.

Hi Hans-Bernhard,

On 7/22/2011 1:34 PM, Hans-Bernhard Br�ker wrote:
> On 22.07.2011 14:22, Rich Webb wrote:
>> On Fri, 22 Jul 2011 10:54:24 +0200, Tilmann Reh
>> <usenet2007nospam@autometer.de> wrote:
>>
>>> maybe you aren't aware of it, but you are starting a new thread
>>> everytime you post an answer.
>>
>> That may depend on the news reader or, possibly, on the Usenet server
>> one is using.
>
> No, it doesn't. The problem is entirely and exclusively with posts
> originating at Google Groups, and the problem is that their posts lack
> the References: header. Yes, some news clients can be told to ignore
> broken References and construct threads based on Subject similarity. But
> that's just wrong.

+42

Google is taking the MS attitude, here.  I.e., we're going to
ignore what has been done before and come up with Our Own Way
Of Doing Things -- even when doing what was done previously
would incur little or no cost.

Or, they are just plain incompetent.

On Fri, 22 Jul 2011 22:34:01 +0200, Hans-Bernhard Br�ker
<HBBroeker@t-online.de> wrote:

>On 22.07.2011 14:22, Rich Webb wrote:
>> On Fri, 22 Jul 2011 10:54:24 +0200, Tilmann Reh
>> <usenet2007nospam@autometer.de>  wrote:
>>
>>> Dave,
>>>
>>> maybe you aren't aware of it, but you are starting a new thread
>>> everytime you post an answer.
>>
>> That may depend on the news reader or, possibly, on the Usenet server
>> one is using.
>
>No, it doesn't.  The problem is entirely and exclusively with posts 
>originating at Google Groups, and the problem is that their posts lack 
>the References: header.  Yes, some news clients can be told to ignore 
>broken References and construct threads based on Subject similarity. 
>But that's just wrong.

However, in this case the original message header contains the line
Message-ID:
<eb8faea3-b10f-4faa-9bef-acda2bd7f39b@glegroupsg2000goo.googlegroups.com>

and the header in the message from Dave N that prompted the "starting a
new thread" comment contains the line:
In-Reply-To:
<eb8faea3-b10f-4faa-9bef-acda2bd7f39b@glegroupsg2000goo.googlegroups.com>

It looks like RFC 5322 permits either or both, with the in-reply-to
field containing the single message id and references optionally
containing all of the message ids of the thread.

<shrug> Agent seems to handle threading with only the in-reply-to field
just fine. How much, or whether, Google's implementation is broken is
above my pay grade; I'd punt to the IETF.

-- 
Rich Webb     Norfolk, VA

On 22.07.2011 23:46, Rich Webb wrote:

> It looks like RFC 5322 permits either or both,

Which is quite irrelevant here, since that's the RFC for E-Mail.  This 
is not E-Mail, but News.

The chapter and verse Google groups is clearly in violation of is RFC 
5537, section 3.4.3 , paragraph 5:

5.  The followup MUST have a References header field referring to its
        precursor, constructed in accordance with Section 3.4.4.

And I'm pretty sure GG broke that on purpose.  Mere negligence just 
doesn't explain the level of blatant incompetence they've repeatedly 
reached whenever make any change to their service.

Hi Hans-Bernhard,

On 7/22/2011 4:30 PM, Hans-Bernhard Br�ker wrote:

> And I'm pretty sure GG broke that on purpose. Mere negligence just
> doesn't explain the level of blatant incompetence they've repeatedly
> reached whenever make any change to their service.

Assuming Google does nothing without a *reason*, this begs the question:
what do they gain by doing this?  (since gain they must!)

On Fri, 22 Jul 2011 19:40:49 -0700, Don Y <nowhere@here.com> wrote:

>Hi Hans-Bernhard,
>
>On 7/22/2011 4:30 PM, Hans-Bernhard Br&#4294967295;ker wrote:
>
>> And I'm pretty sure GG broke that on purpose. Mere negligence just
>> doesn't explain the level of blatant incompetence they've repeatedly
>> reached whenever make any change to their service.
>
>Assuming Google does nothing without a *reason*, this begs the question:
>what do they gain by doing this?  (since gain they must!)

AAaaaaaaaa!!!111...   *RAISES* the question not *begs* the question!

-- 
Rich Webb     Norfolk, VA

On Fri, 22 Jul 2011 22:34:01 +0200, Hans-Bernhard Bröker wrote:

> No, it doesn't.  The problem is entirely and exclusively with posts
> originating at Google Groups, and the problem is that their posts lack the
> References: header.  Yes, some news clients can be told to ignore broken
> References and construct threads based on Subject similarity. But that's
> just wrong.

I'd agree that using Subject headers for threading is wrong; modifying
the subject breaks threads, while unrelated messages with "generic"
subject get bundled into the same thread.

However, some readers (including Pan) can maintain the threading based
upon the In-Reply-To header, and that doesn't have these problems. Relying
upon this has the problem that a missing message will break the thread,
which is why the References header exists (but that has its own problem,
namely that it can become unreasonably long), but there's no harm in
a news reader using In-Reply-To as a fallback in the event of a missing
References header.