Hi. My suggestion is that eqtype should work with the label keyword to differentiate between numeric constants: eqtype label. Example:

Code:

a:;label
b dd 0;label
c=1;constant
if a eqtype label
'true,islabel'
end if
if c eqtype 0;true,isnumber
if c eqtype label ;butnotlabel/name/memory'false,isconstant'
end if
end if

Without such feature, there is no safe way to create HL variables with type/size/sign information and perform error checking in macro languages. No good way to tell the difference between numbers and labels.

Actually eqtype operator accepts directive names as valid operand(s), though the result is somewhat different: it checks whether both operands are directive names.

----8<----
m3ntal,

eqtype is the one of if directive operators that gets preevaluated by the parser, before the assembly stage occurs (hence no type information is available yet; in fact, the assembler simply won't see the falsy block contents provided that the parser has determined the if condition beforehand).

And if you just formally say, that everything defined by the equality sign is a variable, then consider, how the above cases would affect the type checking, you wanna implement.

Btw. the only functional difference between a label and a constant — i.e. something you call variable, that is never redefined — is that constants do not become prefixes for labels/variables starting with a single dot. Do you really want to use this subtle difference as a conclusive factor for your type or whatever error checking?

baldr: I understand how it works currently and the classification of symbols, but I think there should be an exception for eqtype label OR some way to differentiate between numbers and labels.

l_inc: What's the difference? A variable will have a standard label (a: or label a or a dd 0) defined for it. Not all labels are the same. As you know, there is a difference between and a: dd 0 and a dd 0 which has a known size. That's why this works with no type cast: mov [a], 1. FASM knows the difference internally. Another difference is that if defined name works for labels but not for numerics and is the current method I'm using (name$#type). Please don't say something is impossible just because you can't think of a way to do it.

Quote:

if you just formally say, that everything defined by the equality sign is a variable... only functional difference between a label and a constant — i.e. something you call variable, that is never redefined...

That's ridiculous. None of those are variables. A variable is a label with type/size/sign associated with it. Try making a compiler or assembler then you will understand this.

I'm working on a preprocessor for my ARM assembler and it's getting pretty advanced. It does 3-4 scans/passes to supports numeric constants and labels with forward references. It uses the # prefix for numeric constants - # a=0,b=1,c=2 - to eliminate any conflict. It is both assembler AND HL compiler. For example, here is how I create labels:

m3ntal
First of all, when I said variables, I was referring to the compile-time variables as well as compile-time constants. Therefore most part of your answer has nothing to do with my comment.

Quote:

Another difference is that if defined name works for labels but not for numerics and is the current method I'm using (name$#type).

I assume here, when you say "numerics" you mean the compile-time variables and compile-time constants. In this context I don't think the remark "another difference" makes any sense, because what you was referring to before were run-time variables. Besides the statement is just wrong, because defined works for both "numerics" and labels.

Quote:

Please don't say something is impossible just because you can't think of a way to do it.

I have no idea, what you're talking about, cause I didn't say something is impossible. I said, that equtype label made no sense, because the only difference between a label and a compile-time constant is being able to become a prefix.

FASM should have the ability to distinguish numbers from labels for HL variables, type safety and error checking. I can do this in my preprocessor by assigning a type to each defined name (constant='n', label='l', variable='v', etc).

I really don't care either way, not enough to argue. I have my own development utilities and can implement whatever I desire.

Quote:

Any number can functionally be a label as well. The difference is in the programmers head only.

It is true that a label equates to a number, and from that perspective, there is no difference, but a constant is not necessarily an address. Label=Address/Offset. Constant=Any number. In HL compilers (and macro languages), there is a distinction. Assembler is unforgiving and has no type safety. One slight mistake and it crashes.

Quote:

That's not a hack. That's just a bug in your code.

That's the simplest example of variables and is not exactly how I do it. Your check to ensure it's not '' makes it even more of a "hack" though it may solve the problem with '' constants.

Quote:

What you shouldn't do anyway is to make conclusions based on unverified assumptions.

Well, I see no evidence, no reason to believe. Never seen any assembler code from you, not to mention one program. By the way, I learned what I know about FASM by studying Tomasz's code.

Note: Some so-called HL syntaxes - conditional execution, if-then-else (it) blocks and pointer arithmetic (*p++) - are actually native instructions on ARM (M68k has even more advanced pointer syntaxes). So, the ones who say "Don't use if" or "Don't use *p++" are seeing "assembler" strictly through the lens of a X86-only programmer.

In HL compilers (and macro languages), there is a distinction. Assembler is unforgiving and has no type safety.

Yes. And yes. And as long as fasm is an assembler there is not much difference between labels and numbers in fasm. You can create the difference in your own HL constructs by implementing those in macros.

Quote:

Well, I see no evidence, no reason to believe

I don't try to teach you religion and I don't announce facts, that have to be believed as is. Read, understand and only then agree or disagree. You don't need to believe, if you're able to think yourself.

Ok, but the typical definition of a label is a name that represents a location/address/offset. Saying that it's a number is vague. What type of number? Technically, everything is a number: opcode, register, mode, etc.

shutdownall
First of all, please, note, that the discussion is in the context of fasm. Considering this...

Quote:

An address can be any number in valid address range. That's the point.

The valid address range of a label equals to the valid value range of a numeric constant/variable.

Quote:

You can not assign a floating point value to a label

I cannot do so with numeric constants/variables either.

Quote:

nor can you use a 64 bit value when using 32 bit (use32)

Oh, I can:

Code:

use32
label lbl1 at 0x100000000
label lbl2 at -1
dq lbl1
dq lbl2

Moreover, I even consider this to be very handy for some use cases. I never checked, if a eip-overlay is possible, but I think the behaviour could be similar to the ip-overlay in 16-bit code. I mean the instructions could be fetched not from eip, but from rip>=2^32 being at the same time in 32 bit mode.

shutdownall
I can't understand people wittingly using older and buggy versions of software instead of newer and improved ones. The bug was fixed in 1.71.11.

Quote:

I don't know about recent changes - anyway I would prefer the correct context.

The context of use32 defines the code generation mode only. It does not and must not define how numeric calculations (including those with labels) are performed. As I said before, I'm not sure, but I think it might be possible to execute 32 bit code at addresses beyond 2^32, in which case it's very desirable to make sure the compiler knows this and can verify fulfillment of additionally applied restrictions. There's a number of other possible use cases.

Quote:

Naturally every address represents a numeric value - on the other hand not every numeric value represents an address.

You are missing the main difference between low level and high level languages. Low level is more control to the programmer and less control over the programmer. The address semantics of a label in fasm is in the programmer's head only. I as a programmer wanna decide myself if I define a 64 bit label in 32-bit code generation mode context. This might be meaningful and the compiler just can be unaware of that meaningful semantics.

Quote:

My dick has 170 mm length

I don't think you prefer a compiler to tell you "value out of range", because it knows it's 120 mm at most.

Quote:

Numeric values without a dimension is not more than abstract mathematics - nothing to do with addressing at all.

You're again losing the context. It's still fasm. Every number representable in fasm can be (I don't say "is") a valid address. No matter what current code generation mode is.

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