flat assembler
Message board for the users of flat assembler.

Index > Main > flat assembler 1.71.18

Author
Thread Post new topic Reply to topic
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7721
Location: Kraków, Poland
Tomasz Grysztar
This is a new development release (I'm staying with the 1.71.17 as the current stable semi-milestone) which introduces a new experimental feature: the IRPV directive.

This is another variant of IRP which instead of iterating through the directly specified list of values, iterates through all the stacked values of symbolic variable.

Every time the symbolic variable is re-defined (with EQU of DEFINE), the new value is put on top of the stack of the values for this symbol, and RESTORE directive can be used to remove the value from the top. Up to this release, only the top value could be accessed under any circumstances, so the only way to see the other values in the stack was to consecutively remove the top ones with RESTORE. The IRPV allows to access all these values without modifying the stack.

A few samples:
Code:
char equ 'a'
char equ 'X'
char equ '0'+7

irpv current,char { display current }

x equ 1
x equ eax
x equ 3*7

irpv x,x { common process x } ; produces "process 1,eax,3*7" line    

The IRPV also allows what was not possible before: to determine whether the symbolic variable has any value assigned at all. If no value was ever assigned to a given symbol, the IRPV directive will do no iteration at all.
Code:
irpv any,MYLIB
{
     err "This macro library was already defined."
}

define MYLIB

; ...    


Currently IRPV allows to iterate through only a single symbolic variable, so its arguments are just two names separated with comma - the name of the iterating parameter and then the name of symbolic variable to be iterated through. As you can see in one of the above examples, there is no problem in using the same name for both. However if you use different names, it is possible to operate on the variable's stack and it does not interfere with the IRPV execution (the values that are iterated through reflect the state of the stack at the moment when IRPV started). For example, this removes any of the values that the "a" variable had:
Code:
irpv any,a { restore a }    

Because different variables may have stacks of different sizes, I did not decide to try allowing a more complex syntax to iterate through more one than one at the same time - I think it could create more problems that actually solve.
Post 02 Feb 2014, 13:48
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
A curious result:
Code:
irpv x, { display x }    
Gives:
Code:
flat assembler  version 1.71.18  (1048576 kilobytes memory)
1 passes, 0 bytes.    
Post 02 Feb 2014, 14:04
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7721
Location: Kraków, Poland
Tomasz Grysztar
Looks like an undocumented feature. Wink May get removed in the future release.
Post 02 Feb 2014, 14:19
View user's profile Send private message Visit poster's website Reply with quote
Roman



Joined: 21 Apr 2012
Posts: 595
Roman
How about add to Fasm setup colors for user comands instructions !

I use macro Block in my program. And i want change color for Block .

In Fasm setup need add change for macro color
Post 02 Feb 2014, 17:55
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7721
Location: Kraków, Poland
Tomasz Grysztar
I updated the fasmw package with the new version of "struct" macro that is simplified thanks to the IRPV directive. I doubt it has any noticeable impact on the processing cost, but at least the new version looks a bit better.

Roman wrote:
How about add to Fasm setup colors for user comands instructions !

I use macro Block in my program. And i want change color for Block .

In Fasm setup need add change for macro color
I do not currently plan to expand fasm'w syntax highlighting capabilities, see the previous thread where I explained why it is in such a state.
Post 02 Feb 2014, 18:16
View user's profile Send private message Visit poster's website Reply with quote
tthsqe



Joined: 20 May 2009
Posts: 724
tthsqe
Roman, I just posted my syntax modifications at http://board.flatassembler.net/topic.php?t=16301. In order to highlight all of the instructions, it seems to add about 50KB of bloat to fasmw.exe, which it seems that Tomasz wants to avoid.
Post 02 Feb 2014, 18:28
View user's profile Send private message Reply with quote
sid123



Joined: 30 Jul 2013
Posts: 340
Location: Asia, Singapore
sid123
Just a suggestion :
Would a CPU directive be hard to make?
For example I'm trying to write an OS for 386 and above processors,
so I am preventing the use of 386+ instructions however it'd be nice if
we have something like this :
Code:
cpu 80386    

And if FASM finds any instruction that does not belong to 386 it should
spit out a warning like
Quote:
Warning! Line 27 : BSWAP, not a 80386 Instruction, Target CPU set to 386
Post 03 Feb 2014, 11:06
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
sid123 wrote:
Just a suggestion :
Would a CPU directive be hard to make?
For example I'm trying to write an OS for 386 and above processors,
so I am preventing the use of 386+ instructions however it'd be nice if
we have something like this :
Code:
cpu 80386    

And if FASM finds any instruction that does not belong to 386 it should
spit out a warning like
Quote:
Warning! Line 27 : BSWAP, not a 80386 Instruction, Target CPU set to 386
See here for something that might be what you want:

http://board.flatassembler.net/topic.php?t=6921
Post 03 Feb 2014, 11:39
View user's profile Send private message Visit poster's website Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4237
Location: 2018
edfed
sid123 wrote:
Just a suggestion :
Would a CPU directive be hard to make?
For example I'm trying to write an OS for 386 and above processors,
so I am preventing the use of 386+ instructions however it'd be nice if
we have something like this :
Code:
cpu 80386    

And if FASM finds any instruction that does not belong to 386 it should
spit out a warning like
Quote:
Warning! Line 27 : BSWAP, not a 80386 Instruction, Target CPU set to 386


no! this kind of masmery have nothing to do in fasm. the instruction set limitation comes before writing any line of code.

first:
design what you will code (for what and why)

second:
implement a test for the code you will write

third:
code the code in respect to the what and why.

fourth etc...:
iterate until it works and fits your requirement.

here, i cannot see when you will insert unsupported instruction in your code.
Post 03 Feb 2014, 13:31
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
edfed wrote:
no! this kind of masmery have nothing to do in fasm.
More than just MASM support this sort of ISA setting. I think fasm can be improved by including it. It is not always obvious or easy to avoid using a newer instruction on an older CPU target. Best to let the assembler figure out all the small details and report back any discrepancies it finds.
Post 03 Feb 2014, 13:59
View user's profile Send private message Visit poster's website Reply with quote
shutdownall



Joined: 02 Apr 2010
Posts: 518
Location: Munich
shutdownall
That maybe simple for older CPUs like 386, 486 like instruction cycle counting. Now it is not always clear what type of CPU supports what particular instruction or better say feature could be find out just by reading MSR registers in runtime.

Quote:
With the introduction of the Pentium processor, Intel provided a pair of instructions (rdmsr and wrmsr) to access current and future "model-specific registers", as well as the CPUID instruction to determine which features are present on a particular model. Many of these registers have proven useful enough to be retained. Intel has classified these as architectural model-specific registers and has committed to their inclusion in future product lines.


And this could be extended by involving errata sheets as well, at which model which feature may be not working as expected. Razz
Post 03 Feb 2014, 18:05
View user's profile Send private message Send e-mail Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< 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


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.