How the FreeBSD developers solve problems that are not resol

Status
Not open for further replies.
Re: How the FreeBSD developers solve problems that are not r

I don't understand your question really. If the kind of hackery you linked is required to get a job done then it's done that way. If I was a FreeBSD developer and I was faced with such a problem that's exacly what I would do. What is the objection to manual encoding of opcodes if it produces valid code?

Also,

But the developers of FreeBSD not write binary code manually

What is your source for this claim?
 
Re: How the FreeBSD developers solve problems that are not r

Of course you write in assembler using the supported mnemonics if you have to but if the tools you're using do not support something you absolutely need then what else there is to do than use the methods that are available to you, such as the manual encoding with binary code.

Please point out a source code file in the currently supported versions of FreeBSD where such technique is actually used and then you might actually have a point, otherwise this is just purely academic pondering.
 
Re: How the FreeBSD developers solve problems that are not r

Maybe I'm not much of a low level developer, but I don't see any "binary" coding there. I see some C code which defines five single lines of assembly. The assembly uses the ".move" instruction to assign a hex value to a variable.

Im sure you'll find many places in FreeBSD source code where the move assembly instruction is used to assign a hex value to a variable.

"Writing binary code" would require authoring a non-ascii file using a hex editor, and directly entering a sequence of instruction codes (basically writing an executable directly by hand). You would not be able to view this code in anything other than a hex editor.

I'm not aware of anything in FreeBSD (and probably other OS's) that requires directly creating binary executables by hand. However, If there was a function that absolutely couldn't be done any other way, I am certain the FreeBSD devs would create the binary code, just like any other developers implementing that function would have to.

Almost all operating systems are written in C. Some small things are written in assembly either bacause they can't be done in C, or they need to be extremely high performance. There may even be situations where certain values are put into certain registers using assembly, in order to call features not exposed through normal instructions. I wouldn't call that binary coding though, it's still just assembly.

What interests me is why the question even came up in the first place or why it matters to you? What difference does it make if FreeBSD developers write any "binary code". They will implement whatever is required to make the OS do what it needs to.
 
Re: How the FreeBSD developers solve problems that are not r

So what if I did edit my first reply? Work on what you have there now and not on what is no longer there. I had my reasons to edit the post and were not related to the other replies in this thread.

What is this now, a cross-examination on whether everything I have written on the subject checks out?
 
Re: How the FreeBSD developers solve problems that are not r

The question here doesn't seem very clear. Are you asking why the developers don't write pieces of code directly in binary? If so, then it is probably because they don't need to. Writing directly in binary is difficult, extremely error prone, and hard to debug.

I ask, what point are you trying to make here? Does it even matter if they developers use opcodes to perform a task rather than just finding a way around that instruction?
 
Re: How the FreeBSD developers solve problems that are not r

Removed. Again. If you encounter anyone ranting randomly about Assembler and/or spewing conspiracy theories about binary programming and FreeBSD mailing lists (especially the Brazilian ones), just report the post and we'll clean up.

Closed. Sorry you wasted your time. It would not have served any purpose.
 
Status
Not open for further replies.
Back
Top