Reply by David Brown May 9, 20082008-05-09
Grant Edwards wrote:
> 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 /\/\/\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/