Re: What's the easiest and/or simplest part of Linux Kernel?
On Thu, 2013-08-29 at 09:08 +0200, Ralf Mardorf wrote:
> On Thu, 2013-08-29 at 07:06 +0200, Ralf Mardorf wrote:
> > On Thu, 29 Aug 2013 02:02:11 +0200, <berenger.morel@neutralite.org> wrote:
> >
> > >
> > >
> > > Le 29.08.2013 01:13, Cousin Stanley a écrit :
> > >> Ralf Mardorf wrote:
> > >>
> > >>> ....
> > >>> Assembler always is optimized code.
> > >>
> > >> Not always .... :-)
> > >>
> > >> One can also write stinky code in assembler.
> > >>
> > >> Like any programming language,
> > >> some programmers are better at it
> > >> than others ....
> > >>
> > >>
> > >> --
> > >> Stanley C. Kitching
> > >> Human Being
> > >> Phoenix, Arizona
> > >
> > > This is something I understood very recently, and the reason for which I
> > > stopped to aggressively disdain Java and C#. The problem is not the
> > > language, it's the language's user. Always. If eclipse is slow, huge and
> > > buggy (in my experience, 2 years ago, it was.), it's not because it's
> > > written in Java, there are very good programs written in Java, and in
> > > Debian, you can find games with graphics of 90s, written in C or C++,
> > > which are slow as hell on a modern computer.
> > >
> > > And nowadays compilers can make code better optimized than you could,
> > > too. The question is, what is real optimization? Speed? Size? How many
> > > of one? Or of both?
> > >
> > > Before that, I learn that it was not windows itself which was buggy, but
> > > the softwares I was using. I discovered that last one when I discovered
> > > linux, and had some crashes ;)
> > > Sounds like it's easy to say it's the language/OS 's fault, and never
> > > the programmer's one. Probably easy, but so often wrong.
> > >
> > > I think time made me wiser on those points. (funny to notice that when I
> > > was a windows users, I was used to write "window$" and "M$" and other
> > > insulting transformations which are far worse. Stopped that by
> > > discovering another OS.)
> >
> > I guess a high level language like C, Pascal, Basic etc. is harder to
> > learn than Assembler, while there for sure are reasons that you nowadays
> > program in C. Optimal optimization are speed, size, functionality and
> > stability. Sure, first steps can be easier done with high level languages,
> > but the result usually will be spaghetti code.
> >
> > Clear formatted, easy to understand, but insane:
> >
> > Output_to_screen_command "Hel"
> > jump_to label_x
> > label_y
> > Output_to_screen_command "world"
> > jump_to_label_z
> > label_x
> > Output_to_screen_command "lo "
> > jump_to label_y
> > label_z
> > finish_program_command
> >
> > So you learned how to make your computer say "Hello world" and how to jump
> > in R.A.L.F., but you did not learn when it's useful and when it's insane
> > to use the jump command in R.A.L.F. ;).
>
> PS:
>
> A coder can be aware that for a multiplication e.g. only integer
> multiples of 2 without overflow could happen, so the code for the
> multiplication only will be rolling bits and not including a rout, that
> is able to do any kind of multiplication. If a coder would use a high
> level language and use "x * y" the code isn't optimized anymore, but
> instead it's unneeded bloated.
PPS: Even for x * 2, x * (2 * 2) etc., while x is defined as integer,
since a compile couldn't be aware, if there is or isn't the need to take
care for overflows.
Reply to: