mov rcx, FFFFFFFFh    

The numbers in the expression are by default treated as a decimal, binary numbers should have the b letter attached at the end, octal number should end with o letter, hexadecimal numbers should begin with 0x characters (like in C language) or with the $ character (like in Pascal language) or they should end with h letter. Also quoted string, when encountered in expression, will be converted into number - the first character will become the least significant byte of number.

Numbers are distinguished from names by the fact that they either begin with a decimal digit, or with the "$" character followed by any hexadecimal digit. This means that a token can be considered numeric even when it is not a valid number. To be a correct one it must be one of the following: a decimal number (optionally with the letter "d" attached at the end), a binary number followed by the letter "b", an octal number followed by the letter "o" or "q", or a hexadecimal number either prepended with "$" or "0x", or followed by the character "h". Because the first digit of a hexadecimal number can be a letter, it may be needed to prepend it with the digit zero in order to make it recognizable as a number. For example, "0Ah" is a valid number, while "Ah" is a name.

But also note that you can't encode this number for RCX. Instead you can sign extend it to 0FFFFFFFFFFFFFFFFh, or perhaps more simply -1.

revolution wrote:

But also note that you can't encode this number for RCX. Instead you can sign extend it to 0FFFFFFFFFFFFFFFFh, or perhaps more simply -1.

MOV to register has an encoding with 64-bit immediate field, so it is possible in this specific case.

Just use 0xFFFFFFFF, problem solved. Superior notation anyway.

(because C/C++ also use it and they are the best HLL languages )

Furs wrote:

(because C/C++ also use it and they are the best HLL languages )

This is obviously another statement that is going to be considered very subjective on the board that has many followers of the Niklaus Wirth ideas (myself included) and you would not have to look long for a case of someone having a critical opinion on the superiority of C/C++. I think of much of my work as dedicated to providing some kind of counterbalance to the language designs that went "mainstream", even thought that may be a lost battle and the future generations may grow up thinking that some of the choices that became the most popular could not have been any other way, while in fact many of them were a product of forgotten limitations or coincidences, years later considered "obviously a good choice" mainly because of the habitualization. I think this may even be similar to how the music preferences form.

a = 5; b = 6;    

let a be 5; let b be 6;    

I don't like to think of things like this as better or worse, but rather just different, and for different purposes, different needs, different prices, different power usages, different memory sizes, different ...

Fortunately popularity does not equate to better. The former is quantifiable, the latter is subjective.

A note on a margin: this is just a curiosity, but early versions of fasm were so strongly case-sensitive that all hexadecimal digits had to be upper case. But thanks to that these early releases allowed hexadecimal numbers to start with a letter - for example "Ah" was a valid hexadecimal number, distinguished only by the case from the x86 register "ah".

I'm actually glad I never saw those versions. I might never have come back to see a later version. I would have been scarred for life.

Also, Lisp is a nice concept but again, the syntax is horrendous. It's great that it is compact and is less ugly than some Perl's "compact syntax", but the parentheses just throw me off. They just look so intimidating.

0hffffffff
0xffffffff
0ffffffffh
$ffffffff
hex(ffffffff)
ffffffff_hex    

For a start it obviously requires ALL hex numbers to start with a '0' whether they need to or not. That's inefficient and just plain DUMB!!

Secondly it uses 'x' for hex. That's about as logical as using 'y' for assembly or 'r' for assembler... h is for hex, just as d is for decimal etc.

1234UL    ; unsigned long integer, base 10
0x1234UL  ; unsigned long integer, base 16
1.0f      ; single-precision floating point constant    

1234hUL   ; WTF is this hUL unit/format?!?    

Thirdly, it precedes the hex number with its stupid notation which probably prevents the 2-char sequence '0x' ever being used as a string elsewhere, at least not without some useless warning message from the compiler...