flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Linux > Store CPUID values into a String

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
system error



Joined: 01 Sep 2013
Posts: 519

rugxulo wrote:

system error wrote:

It's not about beautiful looking code. It's about semantics. People created textual symbols and symbolic languages because they didn't want to get confused with similar-looking patterns which proven to be error-prone by the past machine coders.

It's like naming your kid as Tyrone, and his kids as Tyrone, and their next kids as all Tyrone. Is it wrong? No but it creates a very confusing semantics. Imagine the family name....



Sorry for going off-topic. (Perhaps this and my last post should be split off into the Heap.)

There's a lot that could be said on this, even though I'm no expert. Redundancy is bad when you're trying to be exact, but that's why there are many ways of identifying something, and context matters a lot. Generally speaking, the smaller number of reserved words, the better. But a lot of times "reserved", even in traditional programming languages, only applies to certain sections of the grammar. So you can't necessarily use "if" as a variable in C, but you can make a structure member (or indeed several, since C89 or MASMv6) named that. (Example omitted because it's pointless.)



I think there are case-sensivity and dotted string features for dealing with similar-looking identifiers (if such necessity ever arises at all, which I doubt it). A good-compiler / language should be able to separate the idea of reserved words, keywords, directives and identifiers as far apart as possible from each other. It should be more strict with an assembler because the reserved words are already and clearly defined in the Manuals.
Post 10 May 2017, 06:39
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 556
That's not true. Things are clearly defined at the point you start the code, but not in the future, and that's the issue. Instructions and "reserved keywords" can be added. Look at the mess C++ is in.

The C++ Committee hates adding new keywords for the reason that they are "reserved" (which is a bad design to begin with, it should be deducible from context). Do you know "requires" is/will be a keyword in C++ now? It didn't use to be, so if you have any variable or function or struct or whatever called requires, it will fail to compile when you upgrade compilers and switch to new standard.

NASM allows you to use "reserved" keywords and deduce them from context, which is arguably better design, you don't risk of having your code fail to compile if you use a newer version of the assembler, because Intel or whoever decided to add an instruction that just so happens to coincide with a label name you used. It's as simple as that.

PS: Theoretically, you can compile most C code with a C++ compiler, however, you cannot compile the Linux Kernel with a C++ compiler. Because it uses the reserved word "class" and probably others. Imagine if C++ replaced C instead of being a new language. It's not unreasonable to use the word "class" for a variable or label at all. (e.g. class of the data code of your structure)
Post 15 May 2017, 11:26
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14923
Location: 6EQUJ5
i remember when crc32 was added to the x86 instruction set. A lot of our code no longer compiled. Fortunately I'm using fasm so I was able to alter the assembler temporarily to get things moving again. And then later I had to go through all the code and change the crc32 label name to something else.
Post 15 May 2017, 11:31
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6435
Location: Kraków, Poland
At least in fasmg you have an option to re-define absolutely everything.
Post 15 May 2017, 12:32
View user's profile Send private message Visit poster's website Reply with quote
system error



Joined: 01 Sep 2013
Posts: 519

Furs wrote:
That's not true. Things are clearly defined at the point you start the code, but not in the future, and that's the issue. Instructions and "reserved keywords" can be added. Look at the mess C++ is in.

The C++ Committee hates adding new keywords for the reason that they are "reserved" (which is a bad design to begin with, it should be deducible from context). Do you know "requires" is/will be a keyword in C++ now? It didn't use to be, so if you have any variable or function or struct or whatever called requires, it will fail to compile when you upgrade compilers and switch to new standard.

NASM allows you to use "reserved" keywords and deduce them from context, which is arguably better design, you don't risk of having your code fail to compile if you use a newer version of the assembler, because Intel or whoever decided to add an instruction that just so happens to coincide with a label name you used. It's as simple as that.

PS: Theoretically, you can compile most C code with a C++ compiler, however, you cannot compile the Linux Kernel with a C++ compiler. Because it uses the reserved word "class" and probably others. Imagine if C++ replaced C instead of being a new language. It's not unreasonable to use the word "class" for a variable or label at all. (e.g. class of the data code of your structure)



I don't care about C++. Nobody is talking about C++ here or any other HLL language. C++/C have to come up with their own keywords because they are built from scratch. On the contrary, ASM's keywords are already and clearly defined in the manuals.

When we talk about "syntax", we talk about the human-side of the language, human perceptions, human semantics and rules. Not the machine side. Hence, we call it syntax error rather mnemonics error, because we concern more about the human readers and not the machine.

What is one of the greatest sin in SYNTAX RULES? Using the reserve words to mean something else not intended for its original use and semantics. These rules become conventions and observing it is part of the GOOD PROGRAMMING PRACTICE [GPP]. Surprising to see that NASM breaks this rule considering the fact that it was built on top of strict language such as C.

Things get from bad to worse if you're using AT&T syntax because they completely disregard the suggested keywords in the manuals and just like NASM, they allow such things to happen. I bet you must be a big fan of ATT syntax then, or perhaps the brainfuck! language>

If ASM would ever have to come to that lowest point by whoring up reserved words for other purposes, then you must be happy with BriainFuck language;


Code:
 
-,+[                         Read first character and start outer character reading loop
    -[                       Skip forward if character is 0
        >>++++[>++++++++<-]  Set up divisor (32for division loop
                               (MEMORY LAYOUTdividend copy remainder divisor quotient zero zero)
        <+<-[                Set up dividend (x minus 1and enter division loop
            >+>+>-[>>>]      Increase copy and remainder / reduce divisor / Normal caseskip forward
            <[[>+<-]>>+>]    Special casemove remainder back to divisor and increase quotient
            <<<<<-           Decrement dividend
        ]                    End division loop
    ]>>>[-]+                 End skip loop; zero former divisor and reuse space for a flag
    >--[-[<->+++[-]]]<[         Zero that flag unless quotient was 2 or 3; zero quotient; check flag
        ++++++++++++<[       If flag then set up divisor (13for second division loop
                               (MEMORY LAYOUTzero copy dividend divisor remainder quotient zero zero)
            >-[>+>>]         Reduce divisor; Normal case: increase remainder
            >[+[<+>-]>+>>]   Special caseincrease remainder / move it back to divisor / increase quotient
            <<<<<-           Decrease dividend
        ]                    End division loop
        >>[<+>-]             Add remainder back to divisor to get a useful 13
        >[                   Skip forward if quotient was 0
            -[               Decrement quotient and skip forward if quotient was 1
                -<<[-]>>     Zero quotient and divisor if quotient was 2
            ]<<[<<->>-]>>    Zero divisor and subtract 13 from copy if quotient was 1
        ]<<[<<+>>-]          Zero divisor and add 13 to copy if quotient was 0
    ]                        End outer skip loop (jump to here if ((character minus 1)/32was not 2 or 3)
    <[-]                     Clear remainder from first division if second division was skipped
    <.[-]                    Output ROT13ed character from copy and clear it
    <-,+                     Read next character
]                            End character reading loop

Post 15 May 2017, 18:04
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 556

system error wrote:
On the contrary, ASM's keywords are already and clearly defined in the manuals.

Same with C++ at a certain point in time.

I'm talking about additions to the "language". In the case of asm, this means new instructions which are basically keywords. (in HLLs of course there's no instructions). Instructions that don't exist right now but might in the future. Nobody knows the future.

If you still can't see the point, read revolution's last post about crc32 instruction.

Would you name a label crc32 if it calculated the crc32 before the instruction was available? If so, your code would fail to compile in the future because of name clash with the crc32 instruction.
Post 15 May 2017, 19:52
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 519

Furs wrote:

system error wrote:
On the contrary, ASM's keywords are already and clearly defined in the manuals.

Same with C++ at a certain point in time.

I'm talking about additions to the "language". In the case of asm, this means new instructions which are basically keywords. (in HLLs of course there's no instructions). Instructions that don't exist right now but might in the future. Nobody knows the future.

If you still can't see the point, read revolution's last post about crc32 instruction.

Would you name a label crc32 if it calculated the crc32 before the instruction was available? If so, your code would fail to compile in the future because of name clash with the crc32 instruction.



You are one big time-wasting anomaly in life. One time you support NASM blasphemy for allowing reserved words as identifiers but now you oppose such idea of using them as label. You don't have to work that hard to prove that you're a complete incompetence. Laughing
Post 28 May 2017, 04:26
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 556
Maybe you should take some english lessons first, because clearly you have some issues understanding those that can speak it properly.

So rewind back before crc32 instruction existed (Intel did not create it yet), you have this code:


Code:
call crc32

crc32:
; ...

Code works fine, compiles. Both NASM and FASM compile it. All is good. At this point, your code is perfectly legal.

Years later, Intel add crc32 instruction, FASM makes it "reserved" on new version, now only NASM compiles your perfectly valid code you written, new versions of FASM don't anymore.

Options:
1) change your perfectly VALID code (when you wrote it) which is annoying and I don't "support" it.
2) use any version of NASM
3) use old version of FASM

2 requires no effort if you wrote it in NASM in the first place. Ergo, better design in this respect. The end.
Post 29 May 2017, 10:44
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6435
Location: Kraków, Poland

Furs wrote:
So rewind back before crc32 instruction existed (Intel did not create it yet), you have this code:


Code:
call crc32

crc32:
; ...

Code works fine, compiles. Both NASM and FASM compile it. All is good. At this point, your code is perfectly legal.

Years later, Intel add crc32 instruction, FASM makes it "reserved" on new version, now only NASM compiles your perfectly valid code you written, new versions of FASM don't anymore.

In general this is not as simple as you presented it here. Consider a variant where you have a pointer to function (perhaps witch a switchable implementation dependent on an instruction set):

Code:
     call [crc32]
; ...
crc32 dd 0

This does not work with modern NASM either, the ambiguity is just too strong.

It works in a similar way in fasmg - there are separate classes of symbols for instructions, labeled instructions and symbols that may be used in the expressions (operands) and you can use the same name in a different class with a different meaning, but this still does not prevent problems when an ambiguity arises. In fasmg, to make things clear, when the name is a first symbol in a line the instruction-class symbol always has a priority over others.
Post 29 May 2017, 18:24
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 556
Yeah, NASM isn't ideal design either (what I have in mind), I'm guessing we need a sort of intelligent parser for that (which would make it slower). I don't know FASMG, seems pretty different "goal" than FASM (not just x86 assembler that is), so sorry about that, can it compile all x86 code?
Post 30 May 2017, 10:31
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 519
LOL
Post 04 Jun 2017, 19:27
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.