Date: Sat, 22 Nov 2014 09:52:15 -0200 From: =?UTF-8?Q?fran=C3=A7ai_s?= <romapera15@gmail.com> To: freebsd-questions@freebsd.org Subject: =?UTF-8?Q?Re=3A_A_FreeBSD_developer_told_me_via_private_message_?= =?UTF-8?Q?that_the_the_most_FreeBSD_developers_don=E2=80=99t_develop_in_mach?= =?UTF-8?Q?ine_code?= Message-ID: <CAK_6RwfUgLCj3ckOvgrZXVWUcRsHvq%2BP0VbUAtG4rxasZVC7sQ@mail.gmail.com> In-Reply-To: <CAK_6RweaS5wEbOO8X31dcQ9i70e4Mb6U7TgCewGDkvrJrrZTxw@mail.gmail.com> References: <CAK_6RweaS5wEbOO8X31dcQ9i70e4Mb6U7TgCewGDkvrJrrZTxw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Someone? 2014-11-21 18:57 GMT-02:00 fran=C3=A7ai s <romapera15@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 FreeBS= D > developers don=E2=80=99t develop in machine code, in other words, the mi= nority > 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> =E2=80= =9C or > sometimes the .word <foo> is just hard coded inline when there=E2=80=99s = only going > to be one of them. Sometimes we expose them both in assembly and in C cod= e, > in which case what we do varies a bit to accommodate the different > language=E2=80=99s syntax. It is rare, but has happened, that we only exp= ose it to > C code. > > Generally, though, we try to add support for the opcodes to gas so that w= e > get the constraint testing it does (making sure the opcode is supported a= t > the level you are compiling, making sure it isn=E2=80=99t 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=E2=80=99t understand with the workaround being the assembl= er > directive using .word followed by by some hex value to encode the opcode.= " > > "Most developers of FreeBSD don=E2=80=99t write directly in machine code= in > FreeBSD development, and don=E2=80=99t care. Some developers use the marc= os that I > described sometimes when doing specific, low-level coding. A handful of > developers create the marcos directly or use the .word directives in thei= r > work to make certain things work that cannot work otherwise. > > People generally don=E2=80=99t write in raw machine opcodes. That is inde= pendent > 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 th= at > 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 workaroun= d > 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=E2=80=99t know about which teaching universities do this, but here ar= e several > examples I=E2=80=99ve 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 assembl= er > for the new opcodes, or you need to hand assemble them somehow. Often the= se > are two different skillets, so one engineer gets tasked with adding the n= ew > opcodes, and another has to use them. Often the people using them are ahe= ad > of the people augmenting the assembler, so they hand assemble things. In > FreeBSD=E2=80=99s case, the project chose to freeze gas at an ancient lev= el, 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 nee= d > to hand assemble the =E2=80=9Cegg=E2=80=9D code that runs on the victim p= rocessor. There=E2=80=99s > 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 assemble= r > on many platforms for speed. Kermit is quite large and sophisticated, whi= ch > 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 cou= ld > 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 impressi= ve > bootstrap technique. > 4) Debugging. While not directly writing in machine code, one must do the > opposite and decode instructions sometimes to understand what was happeni= ng > when a trap occurred. Most people rely on the debugger to do this. And it > works most of the time. Sometimes, though, it doesn=E2=80=99t and you eit= her 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 in= to > 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=E2=80=99t think that=E2= =80=99s what you > mean. > > To give a concrete example of #1: gas on FreeBSD didn=E2=80=99t used to s= upport > 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 th= e > 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=E2=80=99t = give > information about which universities teach this, but I do know from first > hand experience that the number isn=E2=80=99t 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? >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAK_6RwfUgLCj3ckOvgrZXVWUcRsHvq%2BP0VbUAtG4rxasZVC7sQ>