> On 2008-05-09, David Brown <david@westcontrol.removethisbit.com> wrote:
>
>>> Never had a chance to embed an Itanium in anything.
>> I was once involved in a prototype for a very large power
>> supply. Because of its odd design, it had a high minimum
>> output current, so in idle we had to burn off about 800W. We
>> used a panel oven, but an embedded Itanium would have given a
>> more compact solution.
>
> The worlds first power supply that runs protien folding
> simulations while idle...
>
"Protein folding" - that's like cooking a steak on top of the box?
Reply by Grant Edwards●May 9, 20082008-05-09
On 2008-05-09, David Brown <david@westcontrol.removethisbit.com> wrote:
>> Never had a chance to embed an Itanium in anything.
>
> I was once involved in a prototype for a very large power
> supply. Because of its odd design, it had a high minimum
> output current, so in idle we had to burn off about 800W. We
> used a panel oven, but an embedded Itanium would have given a
> more compact solution.
The worlds first power supply that runs protien folding
simulations while idle...
--
Grant Edwards grante Yow! Now, let's SEND OUT
at for QUICHE!!
visi.com
Reply by David Brown●May 9, 20082008-05-09
Grant Edwards wrote:
> On 2008-05-09, Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
>
>> A good compiler knows that those are equivalent and do the
>> picking for you.
>
> True. One doesn't always have the pleasure of using a good
> compiler. :)
>
>> That is a good advice. You can learn something. However ...
>> Did you look at some Itanium code or SEAforth code lately?
>
> Can't say that I have.
>
>> Did you learn something or did you awake with a headache?
>
> What I'm usually looking at are pretty standard CISC micros
> like the H8 or MSP430, or vanilla RISC CPUs like the ARM or
> NIOS2.
>
> Never had a chance to embed an Itanium in anything.
>
I was once involved in a prototype for a very large power supply.
Because of its odd design, it had a high minimum output current, so in
idle we had to burn off about 800W. We used a panel oven, but an
embedded Itanium would have given a more compact solution.
Reply by Grant Edwards●May 8, 20082008-05-08
On 2008-05-09, Albert van der Horst <albert@spenarnc.xs4all.nl> wrote:
> A good compiler knows that those are equivalent and do the
> picking for you.
True. One doesn't always have the pleasure of using a good
compiler. :)
> That is a good advice. You can learn something. However ...
> Did you look at some Itanium code or SEAforth code lately?
Can't say that I have.
> Did you learn something or did you awake with a headache?
What I'm usually looking at are pretty standard CISC micros
like the H8 or MSP430, or vanilla RISC CPUs like the ARM or
NIOS2.
Never had a chance to embed an Itanium in anything.
--
Grant Edwards grante Yow! Here I am in the
at POSTERIOR OLFACTORY LOBULE
visi.com but I don't see CARL SAGAN
anywhere!!
Reply by Albert van der Horst●May 8, 20082008-05-08
In article <seCdnTwTA7tRdZLVnZ2dnUVZ_gmdnZ2d@visi>,
Grant Edwards <grante@visi.com> wrote:
<SNIP>
>
>For example, two ways to sum the bytes in a buffer:
>
> unsigned char buf[128];
> unsigned sum = 0;
>
> unsigned i;
> for (i=0; i<sizeof buf; ++i)
> sum += buf[i];
>
> unsigned char *p;
> p = buf;
> while (p < buf + (sizeof buf))
> sum += *p++;
>
>Those two blocks of code do the same thing. On some
>target/toolchain combinations, they're both about the same
>number of bytes/clocks. On some platforms I've used the first
>was significantly smaller/faster. On others, the second was
>significantly smaller/faster.
Going from the first to the second is a standard optimisation
technique called strength reduction (with regard to an address
calculation).
>
>In the fist case, are you better off with an index that's an
>"unsigned" or an "unsigned char" or an "int"? They can be
>significatly different. Always pick something that will work
>on as many platforms as possible, but if there are multiple
>"correct" ways to do something, you might as well pick the one
>that's going to generate the smallest/fastest code for the
>target.
A good compiler knows that those are equivalent and do the
picking for you.
>
>If you want to be more than an amateur doing trivial projects,
>you've got to know your target's instruction set and know what
>code the compiler is going to generate each time you write a
>line of C.
>
>I always set up my makefile so that the toolchain produces a
>mixed C/assembly listing for each module. Anytime I'm not sure
>what the compiler is going to do with a particular construct, I
>look at the listing and see.
That is a good advice. You can learn something. However ...
Did you look at some Itanium code or SEAforth code lately?
Did you learn something or did you awake with a headache?
>--
>Grant Edwards grante Yow! I invented skydiving
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Reply by Albert van der Horst●May 8, 20082008-05-08
In article <4813D4E6.44B6D3BE@yahoo.com>,
CBFalconer <cbfalconer@maineline.net> wrote:
>Walter Banks wrote:
>> CBFalconer wrote:
>>
>... snip ...
>>
>>> but he can combine these, saving a 'ret' execution, some stack
>>> space, and a call. The result is:
>>>
>>> foobar: /* foo code */
>>> ; /* fall through */
>>> bar: /* bar code */
>>> ret
>>>
>>> eliminating two calls and two rets from the earlier code. The C
>>> programmer doesn't have this capability. Believe me, it adds up
>>> over a medium complicated system.
>>
>> You mean something like this?
>>
>> void bar (void);
>> void foo (void)
>> {
>> 0100 9D NOP NOP();
>> bar();
>> }
>> void bar (void)
>> {
>> 0101 9D NOP NOP();
>> 0102 81 RTS }
>> void main (void)
>> {
>> 0103 AD FB BSR $0100 foo();
>> 0105 20 FA BRA $0101 bar();
>>
>> It does add up..
>
>Well, that looks impressive, but you must be loosing something.
>You must be doing something illegal and non-understandable (to a C
>programmer) with one or more of indentation, braces placement,
>illegal statements (a call to foo should never enter bar). I see
>no reason for bar to exit while foo falls through.
Apparently you don't know the first thing about compiler
optimisation. This trick is called tail optimisation and is
a standard technique, with all respect to Walter Banks, who
implemented this technique neatly.
See also http://home.hccnet.nl/a.w.m.van.der.horst/forthlecture5.html
I'm a good assembler programmer myself, and I don't find Banks
claim extravagant, though a little provocative.
> [mail]: Chuck F (cbfalconer at maineline dot net)
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Reply by Neil Cherry●April 28, 20082008-04-28
On Fri, 25 Apr 2008 00:08:56 +0200, David Brown wrote:
> Neil wrote:
>> Walter Banks wrote:
>>>
>>> Neil wrote:
>>>
>>>> Walter Banks wrote:
>>>>> Vladimir Vassilevsky wrote:
>>>>>
>>>>>> You have to resort to assembly in the two special cases:
>>>>>>
>>>>>> 1. The system level work like switching the contexts of the tasks, C
>>>>>> startup code, etc.
>>>>>>
>>>>>> 2. The parts of code where the performance is very critical.
>>>>> In your second point I would qualify it to parts of code
>>>>> requiring exact timing on anything that we have released
>>>>> recently that seems to be the only limitation.
>>>>>
>>>>>
>>>> Do not forget the startup code
>>>
>>> Our startup code is in C.
>>>
>>> w..
>>>
>>>
>>>
>> I am not sure how that works. I am talking about the code that jumps to
>> main after setting up the C environment.
>
> So is he.
>
> There are small bits of the startup that must be in assembler (I use
> embedded assembly within the C code - Walter uses C extensions in his
> compilers that translate directly to matching assembly). But most of it
> can be written perfectly well in C. For example, code to copy the
> initialised data from flash to ram, and to zero the bss, can be written
> in C.
I've written the startup code in C on the SDCC compiler and the small
C comiler. Basically the compiler did nothing and I had to do
everything. I basically wouldn't use this for professional work but
it was simple enough and I just managed everything.
--
Linux Home Automation Neil Cherry ncherry@linuxha.com
http://www.linuxha.com/ Main site
http://linuxha.blogspot.com/ My HA Blog
Author of: Linux Smart Homes For Dummies
Reply by Walter Banks●April 28, 20082008-04-28
CBFalconer wrote:
> Now this shows the fall-thru. Yet, as far as I can see, the C
> source has no way to control it. A foo call here exercises foobar,
> and a bar call is independant. I am not doubting that you can do
> it - I just don't see how you can control it.
There is no need to control it. C is a way to describe the problem
and compiler is responsible for code generation.
As a program evolves the compiler/linker on each build have an
opportunity to start over and create new code based on the
requirements embodied in the source.
w..
Reply by ●April 28, 20082008-04-28
CBFalconer wrote:
> In addition, the assembly programmer always has some
> extra tricks available, that result in shorter and faster
> programs. For example, consider a program than needs functions
> foo() and bar(). It turns out that a foo call is always followed
> by a bar call, but that bar needs to be separately callable.
[...]
> The C
> programmer doesn't have this capability.
But surely the C compiler has the freedom to emit the same
code as the assembly programmer did? I don't know if any
compiler would do it, but if this was a frequent enough
case to optimize, it does not seem too hard to do.
--
Pertti
Reply by Chris H●April 28, 20082008-04-28
In message <MPG.227ee89292430b1798983f@newsgroups.comcast.net>, Mark
Borgerson <mborgerson@comcast.net> writes
>In article <4815376D.EF541A20@yahoo.com>, cbfalconer@yahoo.com says...
>
>A decade or so back, I used the Keil 8051 C compiler
>on a project for one of the smaller variants. I had done
>earlier projects with assembler, but I wanted to take advantage
>of the compiler overlay capability to maximize variable space
>and to take advantage of some of the math library routines.
>IIRC, the CPU had only 2K flash (89C2051).
>
>At that time, IIRC, it was pretty much a "burn and learn" process
>as I didn't have a JTAG debugger comparable to the systems I use
>(and enjoy) for the MSP430 today.
Now I do worry... "burn and .Learn"? The Keil system has one of the
best simulators for 8051 there is.
For the 8051 family there are only a couple of oddballs with the Jtag
debugger on them. Professionals would use an Emulator. They were not
expensive and gave full vision and control of the MCU.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/