{"id":96785,"date":"2017-08-09T07:00:00","date_gmt":"2017-08-09T21:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/?p=96785"},"modified":"2019-03-13T01:15:03","modified_gmt":"2019-03-13T08:15:03","slug":"20170809-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20170809-00\/?p=96785","title":{"rendered":"The Alpha AXP, part 3: Integer constants"},"content":{"rendered":"

The Alpha AXP does not have a “load immediate 32-bit integer” instruction. If you need to load an immediate 32-bit integer, you need to use some tricks. <\/p>\n

We saw last time that loading 8-bit constants can be done by using the ADD<\/code> and SUB<\/code> instructions<\/a>. But there are also instructions that can be repurposed to generate signed 16-bit constants. <\/p>\n

Effective address instructions are basically arithmetic operations disguised as memory operations. (Yes, I know we haven’t learned about memory operations yet.) <\/p>\n

\n    LDA     Ra, disp16(Rb)  ; Ra = Rb + (int16_t)disp16\n    LDAH    Ra, disp16(Rb)  ; Ra = Rb + (int16_t)disp16 * 65536\n<\/pre>\n
The first instruction applies a signed 16-bit displacement to a value in a register and puts the result in the Ra<\/var> register. <\/p>\n
The second one is a little trickier. It takes the signed 16-bit displacement and shifts it left 16 positions before adding it to the Rb<\/var> register. <\/p>\n
Both of these operations operate on the full 64-bit register, so they can produce non-canonical results. <\/p>\n
The basic idea behind loading a 32-bit constant (in canonical form) is as follows: <\/p>\n
    \n
  1. Use the LDAH<\/code>      relative to the zero<\/var> register     to load the high-order 48 bits of the     32-bit constant. \n
  2. Use the LDA<\/code> instruction     relative to the destination register     of the previous instruction     to load the low-order 16 bits.<\/li>\n<\/li>\n<\/ol>\n
    However, the fact that the 16-bit values are sign-extended makes things a bit more complicated. <\/p>\n
    Let’s say that the 32-bit constant we want to load into the t0<\/var> register is 0xXXXXYYYY<\/code>. <\/p>\n
    Let xxxx<\/code> be the result you get when you treat XXXX<\/code> as a signed 16-bit value. Similarly, yyyy<\/code> and YYYY<\/code>. <\/p>\n
    Let S<\/code> be the sign bit of XXXX<\/code>. The canonical form of the constant we want to load is 0xSSSSSSSS`XXXXYYYY<\/code>. <\/p>\n
    If yyyy<\/code> is nonnegative, then we can just load up the two halves of our constant and they won’t interact with each other. <\/p>\n
    \n    LDAH    t0, XXXX(zero)      ; t0 = 0xSSSSSSSS`XXXX0000\n    LDA     t0, YYYY(t0)        ; t0 = 0xSSSSSSSS`XXXXYYYY\n<\/pre>\n
    (Throughout, I will leave out the obvious simplifications if XXXX<\/code> or YYYY<\/code> is zero.) <\/p>\n
    If yyyy<\/code> is negative, then the LDA<\/code> is going to undershoot by 0x10000<\/code>, so we compensate by adding one more to xxxx<\/code>. <\/p>\n
    \n    LDAH    t0, xxxx+1(zero)    ; t0 = 0xSSSSSSSS`XXXX0000 + 0x10000\n    LDA     t0, yyyy(t0)        ; t0 = 0xSSSSSSSS`XXXXYYYY\n<\/pre>\n
    Aha, but this trick doesn’t work if xxxx<\/code> is exactly 0x7FFF<\/code>, because 0x7FFF<\/code> + 1 = 0x8000<\/code>, which has the wrong sign bit. In that case, we need a final adjustment step to put the result into canonical form. <\/p>\n
    \n    LDAH    t0, -32768(zero)    ; t0 = 0xFFFFFFFF`80000000\n    LDA     t0, yyyy(t0)        ; t0 = 0xFFFFFFFF`7FFFYYYY\n    ADDL    zero, t0, t0        ; t0 = 0x00000000`7FFFYYYY\n<\/pre>\n
    Constants that are in the range 0x7FFF8000<\/code> to 0x7FFFFFFF<\/code> suffer from this problem.¹ <\/p>\n
    All of this hassle about creating 32-bit constants has consequences for the Windows NT memory manager<\/a>, as I discussed a few years ago. <\/p>\n
    Okay, so that’s it for loading constants. Next time, we’ll start looking at memory access. <\/p>\n
    ¹ There is a special shortcut for the value 0x7FFFFFFF<\/code>: <\/p>\n
    \n    LDA    t0, -1(zero)         ; t0 = 0xFFFFFFFF`FFFFFFFF\n    SRL    t0, #33, t0          ; t0 = 0x00000000`7FFFFFFF\n<\/pre>\n","protected":false},"excerpt":{"rendered":"
    Building them up a piece at a time.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[26],"class_list":["post-96785","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-other"],"acf":[],"blog_post_summary":"
    Building them up a piece at a time.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/96785","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=96785"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/96785\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=96785"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=96785"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=96785"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}