Searched refs:bit (Results 1 – 4 of 4) sorted by relevance
| /DragonStub/lib/x86_64/ |
| H A D | math.c | 149 UINT32 bit; in DivU64x32()
159 for (bit=0; bit < 64; bit++) { in DivU64x32()
169 sub dword ptr Dividend[0], eax ; set low bit in dividen in DivU64x32()
|
| /DragonStub/lib/ia32/ |
| H A D | math.c | 149 UINT32 bit; in DivU64x32() local
159 for (bit=0; bit < 64; bit++) { in DivU64x32()
186 sub dword ptr Dividend[0], eax ; set low bit in dividen in DivU64x32()
|
| /DragonStub/docs/ |
| H A D | README.gnuefi | 167 is a 32-bit object file format. The plus in "PE32+" indicates that
169 a 64-bit address space (unlike ELF64, however, this is not a full
170 64-bit object file format because the entire binary cannot span more
271 22-bit offset that the "addl" instruction affords. Specifically,
282 However, a start address of 0 makes debugging a wee bit easier
|
| /DragonStub/ |
| H A D | ChangeLog | 286 Subject: [PATCH] Add support for 32-bit ARM
288 This adds support for 32-bit ARM using an approach similar to the one used for
289 64-bit ARM (AArch64), i.e., it does not rely on an objcopy that is aware of EFI
292 In the 32-bit ARM case (which does not have a division instruction), some code
313 Subject: [PATCH 4/4] Add support for 64-bit ARM (AArch64)
315 This adds support for 64-bit ARM (AArch64) environments. Since there is no
909 definitions for uint64_t, int64_t and int8_t. The 64-bit types are now defined
939 to "x86_64." It happens that uname -m on 64-bit FreeBSD reports the former
949 $(TOPDIR)/gnuefi/elf_$(ARCH)_fbsd_efi.lds when building on either 32-bit or
950 64-bit FreeBSD instead of just for the x86_64 case.
[all …]
|