Index
> Main > flat assembler 1.71.18 |
| Author |
|
|
Tomasz Grysztar 02 Feb 2014, 13:48
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. |
|||
02 Feb 2014, 13:48 |
|
|
revolution 02 Feb 2014, 14:04
A curious result:
Code: irpv x, { display x } Code: flat assembler version 1.71.18 (1048576 kilobytes memory) 1 passes, 0 bytes. |
|||
|
02 Feb 2014, 14:04 |
|
|
Tomasz Grysztar 02 Feb 2014, 14:19
Looks like an undocumented feature.
 May get removed in the future release. |
|||
|
02 Feb 2014, 14:19 |
|
|
Tomasz Grysztar 02 Feb 2014, 18:16
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 ! |
|||
|
02 Feb 2014, 18:16 |
|
|
tthsqe 02 Feb 2014, 18:28
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.
|
|||
|
02 Feb 2014, 18:28 |
|
|
sid123 03 Feb 2014, 11:06
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 |
|||
|
03 Feb 2014, 11:06 |
|
|
revolution 03 Feb 2014, 11:39
sid123 wrote: Just a suggestion : http://board.flatassembler.net/topic.php?t=6921 |
|||
|
03 Feb 2014, 11:39 |
|
|
edfed 03 Feb 2014, 13:31
sid123 wrote: Just a suggestion : 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. |
|||
|
03 Feb 2014, 13:31 |
|
|
revolution 03 Feb 2014, 13:59
edfed wrote: no! this kind of masmery have nothing to do in fasm. |
|||
|
03 Feb 2014, 13:59 |
|
|
shutdownall 03 Feb 2014, 18:05
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.  |
|||
|
03 Feb 2014, 18:05 |
|
< Last Thread | Next Thread > |
Forum Rules:
|