On 6/28/19 7:06 PM, Jan Bobek wrote:
> That's true. (Although not in all cases; see Table 2-5 in the Intel Manual,
> Volume 2, Chapter 2, Section 2.2.1 "REX Prefixes" for some cases when REX.B
> is not decoded.) This is a compromise that I've accepted, at least for v1
> of the patch series. Note th
On 6/27/19 6:29 AM, Richard Henderson wrote:
> On 6/19/19 7:04 AM, Jan Bobek wrote:
>> +sub write_mov_reg_imm($$)
>> +{
>> +my ($reg, $imm) = @_;
>> +
>> +my %insn = (opcode => {value => 0xB8 | ($reg & 0x7), len => 1},
>> +imm => {value => $imm, len => $is_x86_64 ? 8 : 4});
On 6/27/19 6:53 AM, Richard Henderson wrote:
> On 6/27/19 12:29 PM, Richard Henderson wrote:
>> On 6/19/19 7:04 AM, Jan Bobek wrote:
>>> +--x86_64 : generate 64-bit (rather than 32-bit) x86 code.
>> Better is to use
>>
>> .mode x86.64
>> vs
>> .mode x86.32
>>
>> or some such,
On 6/27/19 12:29 PM, Richard Henderson wrote:
> On 6/19/19 7:04 AM, Jan Bobek wrote:
>> +--x86_64 : generate 64-bit (rather than 32-bit) x86 code.
> Better is to use
>
> .mode x86.64
> vs
> .mode x86.32
>
> or some such, like we do for aarch64.
>
Nevermind. Unlike aarch
On 6/19/19 7:04 AM, Jan Bobek wrote:
> +--x86_64 : generate 64-bit (rather than 32-bit) x86 code.
Better is to use
.mode x86.64
vs
.mode x86.32
or some such, like we do for aarch64.
> +sub write_mov_reg_imm($$)
> +{
> +my ($reg, $imm) = @_;
> +
> +my %insn =
The risugen_x86.pm module contains most of the code specific to Intel
i386 and x86_64 architectures. This commit also adds --x86_64 option,
which enables emission of 64-bit (rather than 32-bit) assembly.
Signed-off-by: Jan Bobek
---
risugen| 6 +-
risugen_x86.pm | 455 +
