Re: ****tability: Harmony between PC and microcontroller

On May 6, 3:32=A0pm, "sos...@[EMAIL PROTECTED]
" <sos...@[EMAIL PROTECTED]
> wrote:
> On May 6, 9:06=A0am, Tom=E1s =D3 h=C9ilidhe <t...@[EMAIL PROTECTED]
> wrote:
>
> > They can be one in the same thing if the performance affects the
> > usability of the product. If I ****t a web browser to a Nintendo gaming
> > console, is it really a succesful ****t if it takes seven minutes to
> > load a webpage? I don't think it is.
>
> Did it load? Yes? Then, it is.


I'd love to actually have to take a trial of it. I'd love to have you
sit down in a room with a desk and a chair and my machine running the
****ted webbrowser. I'd love to see you type in "google.ie" and wait 7
minutes for it to load.

I'd lose the plot if I had to wait one minute for a page to load, let
alone seven.


> Don't think a nintendo (hey... some
> nintendo can work very fine here... :) hardware was designed to work
> as a http daemon (maybe that is not the product!).


Nintendo was an arbitrary choice on my part by the way.
(Also, the "daemon" is the program that runs on the server, not the
client. The daemon listens on a ****t number, e.g. ****t 80 for HTTP,
and processes requests to that ****t number).


> Performance isn't
> 100% hardware and, isn't too, 100% code. Run a vanilla 2.4 kernel in a
> dual xeon with 1Tb memory, and run the same in a 286 with 1Mb RAM. Do
> you really expect code tuning, best practices or hacks to make both
> run, at least close to each other?


I'm talking about getting optimal performance out of every system,
whether it runs at 31 kHz or 3.6 Ghz.


> Did you pick the wrong language or the wrong hardware (haven't you
> picked C? haven't you picked the 8 bit platform? Why mix them if you
> think that will not work?)?


They work great if used properly.


> That is the question I think you must
> answer before post C standards or limits as the source of your
> problems. The right tools Tom=E1s. The right tools.


I'm not talking about changing tools, or even about critiquing the C
language. I'm talking about adopting a habit of using the likes of
uint_fast8_t instead of int, because it will lead to faster code on
every conceivable platform.