The first beta version of fasm 1.51 is now available as official download on http://flatassembler.net - no new features this time, only some code revisions, optimizations for better speed of compilation of large projects, and some other small fixes.

Thanks!

Hi,

FASM 1.51 beta 1 for MenuetOS?
Is it difficult to porting?

Excuse me (=newbie)
--

ask Ville, he knows

i think no because things you need to change are messages processing and I/O

But i want(sorry for only mouth lives) officially linked in http://flatassembler.net/

--

can u still provide the links for the last stable version(non Beta) on your site?

also, CTRL+HOME doesn't go to the begining of the file.

Here you've got the old releases: http://fasm.sourceforge.net/archive/
But beta release in this case of fasm means stable, though not final. Actually 1.51 is probably even more stable than 1.50, as some crash-causing bugs were fixed.

Please read the "Keyboard commands for Windows version" from the http://flatassembler.net/. FASMW's keyboard layout is very traditional one (based on some old IDEs for DOS), and i'm very used to it.

I open up the HELLO example that came with fasmw151, and compile it getting this error:


I tried other windows applications and still the same error. I have enough memory and fasm 1.50 compiles it fine, what could be the problem?

You can adjust the memory settings in "Compiler setup" window.
But thanks to your notification I realized that I should increase the percent of memory that is used for additional memory block, as 1.51 uses it more that previous releases. I have fixed it and it again is able to compile the HELLO example with the default 4 MB memory setting.

Thanks Privalov!

the best of all is the question who has better fun?
users who have new version or Privalov because of smart code solutions...

I wish YOU Privalov much joy with your interests and work and very thank YOU for your help.

Hi Privalov,
The following code doesn't want to compile (got undefined symbol):


Instead of global_label.local_label it produces SOME_CONSTANTS.local_label. Is this a bug?

It's intended - for parser labels and constants are the same thing. So the constant begins the new local labels space. Do you think I should change it? It would break backward-compatibility, but it would also allow to simplify some macros...

Absolutely the same effect is with local macro labels. So, in many cases we are forced to use double pointet labels ( local ..mylocal ).
And if we bring up this subject, why not to think about how to make multy level labels in the code. Now only data structures may have more than two levels of nested local labels, why not to make it for code too.

Regards

Would that be really useful for something? I even don't have an idea how could it look like in terms of syntax.

Anyway I like the idea of disabling beginning new locals section on the numerical constant - and only one line in PARSER.INC needs to be changed to achieve it. Are you for it?

Yeah, IMO that's good idea. backward compatibility isn't an argument, I dont think that anybody uses numerical constants with local labels.

What about data labels (like "something db 0")?

Well, I have no idea too about syntax. But I know where it may be useful. Actually it is the same idea for local labels and the same reasons, but in a new level. Now, second level of labels, make possible to write internal to subroutines labels with equal names. ( .finish or .quite for example )
But the names of the subroutines still have to be unique in the bounds of the whole project. So, if you write big project with big amount of procedures in the libraries, you have to use the names that must be unique among hundreds and thousends of names.
If it is possible to use one more level of labels, there will be possible to set one common label for whole library and if there are equal names we may use them prefixed with library name. And so on, and so forth...



I am for it.