Re: A FreeBSD developer told me via private message that the the most FreeBSD developers don’t develop in machine code

[françai s]

Someone?

2014-11-21 18:57 GMT-02:00 françai s <romapera15 at gmail.com>:

> This subject is irresistible to me,I like so much of this issue that get
> out tears out of my eyes.
>
> This topic is mainly for developers of FreeBSD that develop in machine
> code, until even in binary code.
>
> A FreeBSD developer told me via private message that the  the most FreeBSD
> developers don’t develop in machine code, in other words, the  minority
> FreeBSD developers develop in machine code, until even in binary code.
>
> Thought I'd share and hope that someone can get some use out of it.
>
> He told me this:
>
> "We either create a macro expands to something like ".word <foo> “ or
> sometimes the .word <foo> is just hard coded inline when there’s only going
> to be one of them. Sometimes we expose them both in assembly and in C code,
> in which case what we do varies a bit to accommodate the different
> language’s syntax. It is rare, but has happened, that we only expose it to
> C code.
>
> Generally, though, we try to add support for the opcodes to gas so that we
> get the constraint testing it does (making sure the opcode is supported at
> the level you are compiling, making sure it isn’t in a delay slot or
> violating some other precondition for its use)."
>
> "You pointed me at macros that defined operations in terms of opcodes the
> assembler didn’t understand with the workaround being the assembler
> directive using .word followed by by some hex value to encode the opcode."
>
> "Most developers of FreeBSD don’t  write directly in machine code in
> FreeBSD development, and don’t care. Some developers use the marcos that I
> described sometimes when doing specific, low-level coding. A handful of
> developers create the marcos directly or use the .word directives in their
> work to make certain things work that cannot work otherwise.
>
> People generally don’t write in raw machine opcodes. That is independent
> of FreeBSD.
>
> However, a few, specialized people will find the need to do it from time
> to time. Usually because they are porting FreeBSD to a newer processor that
> needs newer opcodes to do context switching, optimize interrupt handling,
> code with a new type of cache coherency, etc. These people look up the
> assembler in the docs from the vendor and then create the .word workaround
> to make sure things work. If they have the time, they may add it to our
> somewhat ancient gas assembler as well."
>
> "Almost nobody writes directly in binary. There are some exceptions,
> sometimes though."
>
> "> Exist university that teaches that sometimes it is necessary coding in
> machine code?
>
> My one, personal, first hand experience of being in the industry for the
> last 25 years.
>
> > If yes, what are the countries in that they exist  , if you can not
> speak the names of all countries, please tell only examples.
>
> Don’t know about which teaching universities do this, but here are several
> examples I’ve done or seen in my career.
>
> 1) When the assembler only supports the old processors, but you are
> porting an operating system to it. You need to either enhance the assembler
> for the new opcodes, or you need to hand assemble them somehow. Often these
> are two different skillets, so one engineer gets tasked with adding the new
> opcodes, and another has to use them. Often the people using them are ahead
> of the people augmenting the assembler, so they hand assemble things. In
> FreeBSD’s case, the project chose to freeze gas at an ancient level, so all
> new machines that have new opcodes need to be assembled by hand.
> 2) If you are writing a virus or other attack vector, you often times need
> to hand assemble the “egg” code that runs on the victim processor. There’s
> many variations on a theme here, including writing code that tweaks other
> code to do bad things which is another form of writing machine code.
> 3) KERMIT. Kermit is a file transfer program written entirely in assembler
> on many platforms for speed. Kermit is quite large and sophisticated, which
> was a barrier to entry back in the day before the internet and most
> communications protocols were standardized. To ease the transition, and
> taking advantage of the .COM format in DOS, kermit came with a bootstrap
> program that was made up entirely of printable characters so that one could
> easily type it in (well, not so easily, but it was possible since it was
> only maybe a hundred or two bytes long). The authors of this program had to
> learn which assembler op codes and addressing modes lead to printable
> characters and write their code accordingly. Not exactly programming
> directly in machine code, but very close. It was really quite an impressive
> bootstrap technique.
> 4) Debugging. While not directly writing in machine code, one must do the
> opposite and decode instructions sometimes to understand what was happening
> when a trap occurred. Most people rely on the debugger to do this. And it
> works most of the time. Sometimes, though, it doesn’t and you either have
> to accept that you can get no useful data from the crash, or you have to
> start decoding instructions to find out what went wrong.
>
> Going back even further, there are many others. Back before there were
> good consoles for computers, one had to enter a few words of boot code into
> the switches on the front panel and hit run to start / boot the computer.
> Most of these systems died out around the late 70 or early 80s (though as a
> vestige of the old system, newer models retained the toggle switches to
> allow for older techniques to work).  But I don’t think that’s what you
> mean.
>
> To give a concrete example of #1: gas on FreeBSD didn’t used to support
> the EI and DI instructions for mips32r2 and mips64r2 ISAs. When I ported
> FreeBSD to the Octeon processor, we wanted to make use of these
> instructions. I created macros for the assembler to generate these
> instructions and used them to optimize the context switching code in
> FreeBSD a bit. Later, when someone else added them to gas as part of a
> wholesale importing of new MIPS opcodes, I removed the macros and used the
> native opcodes directly.
>
> So while it is a useful approximation that nobody does it, people do do
> it, have done it forever and there are good reasons that some very small
> number of people will continue to do it into the future. I can’t give
> information about which universities teach this, but I do know from first
> hand experience that the number isn’t 0."
>
> This is all that I want to share.
>
> The following link leads to tutorial that teaches programming Assembly in
> to FreeBSD:
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/x86.html
>
> Also exist tutorial that teaches programming in machine code to FreeBSD?
>