How the FreeBSD developers solve problems that are not resolved by Assembly?
Warner Losh
imp at bsdimp.com
Mon Oct 13 14:59:55 UTC 2014
On Oct 13, 2014, at 6:50 AM, françai s <romapera15 at gmail.com> wrote:
> I think that the only case where you have to resort to writing binary code
> manually
> is when the assembler cannot output the desired code for some reason.
> If I recall correctly, there is only one such case in the HelenOS
> sources:
>
> http://trac.helenos.org/browser/mainline/kernel/arch/mips32/include/debug.h?rev=mainline%2C1446.3.1
>
> Here they manually encode the opcodes of five special debugging
> instructions for the MSIM MIPS simulator (these instructions are not
> part of the standard MIPS ISA, thus the assembler does not know them).
>
> But the developers of FreeBSD not write binary code manually.
>
> How the FreeBSD developers solve problems that are not resolved by Assembly?
More or less the same way. 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).
Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-drivers/attachments/20141013/63fb634d/attachment.sig>
More information about the freebsd-drivers
mailing list