Re: What's the easiest and/or simplest part of Linux Kernel?
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.
Reply to: