flat assembler
Message board for the users of flat assembler.

Index > Main > flat assembler 1.67.3x

Goto page Previous  1, 2, 3, 4, 5  Next
Author
Thread Post new topic Reply to topic
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
Tomasz Grysztar wrote:
Currently I'm working on the core, not IDEs. When I get back to the work on IDE (and I have to do it one day, because they both are still "prototypes"; the things like directory browsing or .ini support are missing in FASMD not because I don't think they're necessary, but just because this is still far from the "final" version


OK ... IMHO FASMIDE.INI should be used and shared rather than FASMD.INI and FASMW.INI. About those 2, they are also on my ToDo list (something I might be able to fix), but no idea when.

My ToDo list is in the "big" thread t=9494 + the calculator t=9679.

Quote:
version 1.67.32 (Feb 13, 2009)

[+] Allowed single quote character to be put inside the number value,
to help improve long numbers readability.


Secret update ? So

Code:
   mov eax, $FFFF'FFFF
    


will work now ? Laughing

Quote:
possibly I should state it more clearly in the documentation draft?


No big need IMHO Wink

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug
Post 14 Feb 2009, 07:55
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7784
Location: Kraków, Poland
Tomasz Grysztar
DOS386 wrote:
OK ... IMHO FASMIDE.INI should be used and shared rather than FASMD.INI and FASMW.INI.
That would not be a good idea, because only few of the settings are identical to both. And I prefer the standard where .INI file with the same name as the executable is used.

As I need to have some EFI feature tests done before continuing with 1.68 release preparations, and those may still take some time to be done, in the meantime I've decided to take a look at FASMD and fix at least some of its shortcomings. Right now I'm uploading the updated DOS package with the version that finally supports the .INI file (read the last section of FASMD.TXT for more info). It also contains a few bugfixes.
Post 17 Feb 2009, 22:36
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
> That would not be a good idea

oops ... Embarassed

> because only few of the settings are identical to both.

+ passes limit
+ memory limit
+ debug output
+ predefinitions

- compiler priority

? colors

> And I prefer the standard where .INI file with the same name as the executable is used.

Good point ...

> Right now I'm uploading the updated DOS package

silent as 1.67.32 ...

> with the version that finally supports the .INI file (read the last
> section of FASMD.TXT for more info). It also contains a few bugfixes.

Thanks Smile

I see that you fixed the thread subject also Smile
Post 18 Feb 2009, 07:17
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7784
Location: Kraków, Poland
Tomasz Grysztar
DOS386 wrote:
>+ passes limit

Oops, I forgot about passes limit setting. Even in fasmw. Very Happy
DOS386 wrote:
+ memory limit

For DOS versions memory setting is useful for a bit different purposes than on Windows, only when for some reason you don't want them to use all the available memory (like if you have DPMI that implements virtual memory with swap file, that would unnecessarily fill your HDD).
DOS386 wrote:
+ debug output

Win32 IDE lacks it too, and it's not high on my TODO list.
DOS386 wrote:
+ predefinitions

This feature of command line versions is unofficial and I plan to leave it undocumented.
Or perhaps you mean environment definitions? That's the one thing where sharing the same .ini file would actually be useful.

DOS386 wrote:
? colors

Yes, colors are defined differently.

DOS386 wrote:
silent as 1.67.32 ...

Well, the updates that don't provide any changes to the core (and thus don't alter its version number) are quite silent. I can fix it a little by providing more detailed date+time of the last update for each package.
Well, time of the last update is anyway the most reliable versioning system. Wink
Post 18 Feb 2009, 19:20
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
First of all, it seems that the Win32 download doesn't have the latest changes (e.g. FASMD.ASM is still dated the 13th). Although in this case, that's a good thing.

No offense, but I think your FASMD changes broke something. It's buggy now, seems to corrupt source after first line once you compile with it. (Tested on 32-bit Windows and DOSBox.) I also tried using *nix LFs, but that didn't help either. (This also happens with FASM's own source, so it's not just my stuff.) Something to do with the first screenful / "page" of source. If you page down a screen before assembling, it still doesn't work: it looks okay until you page back up, then everything is gone! Razz
Post 18 Feb 2009, 21:42
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7784
Location: Kraków, Poland
Tomasz Grysztar
Sorry for that broken release, I was just uploading the fix, when I noticed you already reported it... So I'm a bit late, sorry again. Wink
Post 18 Feb 2009, 22:40
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
rugxulo wrote:
Win32 download doesn't have the latest changes (e.g. FASMD.ASM is still dated the 13th).


Very minor Laughing useless, just for completeness sake

Quote:
No offense, but I think your FASMD changes broke something. It's buggy now, seems to corrupt source after first line once you compile with it. (Tested on 32-bit Windows and DOSBox.)


Why not on DOS ? Crying or Very sad

Quote:
I also tried using *nix LFs


Confused

Quote:
but that didn't help either. (This also happens with FASM's own source, so it's not just my stuff.)


I tested also, on DOS, and YES, the version form yesterday is broken. Sad

Quote:
Fix Vista SP1's DPMI limit: HKLM\System\CurrentControlSet\Control\Wow


I don't have this problem, 100% of my physical memory is accessible to my DOS code Smile WOW

> > passes limit
> forgot about passes limit setting. Even in fasmw.

Wink

> memory limit
> > For DOS versions memory setting is useful for a bit different purposes than on Windows

YES.

> only when for some reason you don't want them to use all the available memory

YES.

> like if you have DPMI that implements virtual memory with swap file, that

is something I avoid as hell Laughing

The most important reason why it is useful is that you can easily find out how much memory is required and write it into the source compiling requirements.

> > debug output
> Win32 IDE lacks it too, and it's not high on my TODO list.

yeah

> > predefinitions
> This feature of command line versions is unofficial and
> I plan to leave it undocumented.

IIRC I've seen this argument already before ...

Nevertheless, I had a better (?) idea ... this could be done in the IDE's as well Idea

> Or perhaps you mean environment definitions?

I meant the evil -D stuff, sorry. But what's the point of environment definitions at all ?

> That's the one thing where sharing the same .ini file would actually be useful.

Smile
Post 19 Feb 2009, 06:20
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
revolution wrote:

Is there? Has anyone done tests? Sure the LEA probably uses the AGU, whereas MOV uses the ALU. But will it create a resource bottleneck? Perhaps using the AGU will free up the ALU for another instruction to be processed in parallel, perhaps it can improve the performance? I'm also guessing.


At least back in 2000 or so (when A86/A386 was last updated) EJI claimed in the docs that LEA was always slower than MOV, and it uses an extra byte anyways (but not in x86-64?). Hence, the reason some assemblers (TASM, LZASM, MASM?) "optimize" it, since both do the exact same thing. I know some people hate it when the assembler does things "behind their back", but this kind of thing is very mainstream and would only affect like 1% of users. I'm just saying, it's not THAT evil. Cool

Tomasz wrote:

I don't want the amount of packages on the server to grow too quickly with all the small mistake fixes.


7-Zip 'em. Or just store the diffs ("diff -Naur 1.66 1.67 > 1.66_1.67.txt") ZIP'd. Or delete all the docs and examples from older versions (since they don't change much anyways).

Tomasz wrote:

For DOS versions memory setting is useful for a bit different purposes than on Windows, only when for
some reason you don't want them to use all the available memory (like if you have DPMI that implements
virtual memory with swap file, that would unnecessarily fill your HDD).


I have yet to see any swapping, but I don't assemble huge files with tons of macros. Anyways, you can actually detect whether the DPMI host supports swapping (int 31h, 400h returns BX with bit 2 set if so). Of course, I can't think of too many that do support virtual memory: QDPMI, CWSDPMI, DPMIONE, dunno who else (some Windows or OS/2, maybe?). I think it's fair to say that CWSDPMI is pretty ubiquitous and probably a common choice to use with FASMD. (All CWSDPMI versions since original 5.0 in 2000 support the DPMI 1.0+ call int 31h 401h, which returns "CWSDPMI" and "5.0" as version. DPMIONE says "DPMIONE" and "0.91", if that helps any.)

Tomasz Grysztar wrote:
Sorry for that broken release, I was just uploading the fix, when I noticed you already reported it... So I'm a bit late, sorry again. Wink


I was just worried that it would slip by unnoticed and bite more people. So the fact that you already fixed it quickly is cool. I was actually worried. Wink

P.S. Glad .INI file colors (supposedly? heh) works. Now I don't have to manually patch FASMD every single time. Wink

EDIT: Heh, DOS386 just barely beat me with his reply! Laughing
Post 19 Feb 2009, 06:30
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
rugxulo wrote:
I have yet to see any swapping


Get DGJPP Idea

Quote:
Anyways, you can actually detect whether the DPMI host supports swapping (int 31h, 400h returns BX with bit 2 set if so


Wrong, doesn't work. I did test.

Quote:
too many that do support virtual memory: QDPMI, CWSDPMI, DPMIONE, dunno who else (some Windows or OS/2, maybe?)


ALL OS/2 and ALL Windaube.

Quote:
I think it's fair to say that CWSDPMI is pretty ubiquitous and probably a common choice to use with FASMD.


I'm still dreaming of a FASM version not requiring any DPMI host at all Smile

Quote:
All CWSDPMI versions since original 5.0 in 2000 support the DPMI 1.0+ call int 31h 401h, which returns "CWSDPMI" and "5.0" as version. DPMIONE says "DPMIONE" and "0.91", if that helps any


True but pretty useless here.

Quote:
url=http://www.delorie.com


>= 10 years old and broken.

EDIT: typos only


Last edited by DOS386 on 19 Feb 2009, 07:01; edited 2 times in total
Post 19 Feb 2009, 06:49
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
DOS386 wrote:
rugxulo wrote:
I have yet to see any swapping


Get DGJPP Idea


I meant with FASM I've never noticed it. (And UPX needs more RAM than DJGPP anyways.)

DOS386 wrote:

rugxulo wrote:
Anyways, you can actually detect whether the DPMI host supports swapping


Wrong, doesn't work. I did test.


With CWSDPMI ?????

DOS386 wrote:

rugxulo wrote:
too many that do support virtual memory: QDPMI, CWSDPMI, DPMIONE, dunno who else (some Windows or OS/2, maybe?)


ALL OS/2 and ALL Windaube.


Have you really confirmed this personally? Because I don't know for sure about Win16, would have to check. And I'm pretty sure Vista does NOT swap (else there would be never be a 32 MB limit).

DOS386 wrote:

I'm still draming of a FASM version not requiring any DPMI host at all Smile


FASM doesn't need it, only FASMD does. Or is that what you meant? Wink

DOS386 wrote:

rugxulo wrote:
All CWSDPMI versions since original 5.0 in 2000 support the DPMI 1.0+ call int 31h 401h


True but pretty useless here.


Not if the other call fails. Most people (except non-DOS users) know that r5 is the latest, and CWSDPMI always supports swapping by default as used by DJGPP. So if you know it's CWSDPMI, you can fairly safely assume swap is enabled.

DOS386 wrote:

rugxulo wrote:
url=http://www.delorie.com


>= 10 years old and broken.


In what way? Sure, some of the links don't work, but most of them do. DJ is pretty vigilant (if not 100%). He hasn't abandoned the site (or DJGPP) by any means.
Post 19 Feb 2009, 06:58
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
rugxulo wrote:
meant with FASM I've never noticed it


Me neither. Never used CWSPMI except for BUG tests against HDPMI32.

Quote:
And UPX needs more RAM than DJGPP anyways


Don't forget P.A.Q. Laughing

Quote:
Quote:
Wrong, doesn't work. I did test.
With CWSDPMI ?????


YES.

Quote:
Have you really confirmed this personally?


YES. Try to kick pagefile.sys Idea

Quote:
Because I don't know for sure about Win16


Also.

Quote:
And I'm pretty sure Vista does NOT swap


I'm pretty sure you're wrong (although I don't have it).

Quote:
(else there would be never be a 32 MB limit).


Argument doesn't work, you can swap out as little as 4 KiB (or 2 or 4 MiB if Vista uses PSE hack).

Quote:
FASM doesn't need it, only FASMD does. Or is that what you meant? Wink


Testing on DOS would have revealed the truth.

Quote:
So if you know it's CWSDPMI, you can fairly safely assume swap is enabled.


Right. So don't trust it.

Quote:
In what way? Sure, some of the links don't work, but most of them do. DJ is pretty vigilant (if not 100%). He hasn't abandoned the site (or DJGPP) by any means.


* Does the BUGZILLA work for you ? OK, maybe it's just me, I got banned for all my rude posts on DGJPP Laughing
* Docs are outdated
* ZIP PACKER still defaults to XP ... no final decision between DOS and W7 yet Laughing
* OpenDOS advertised ... but nobody uses it anymore, and no EDR-DOS
Post 19 Feb 2009, 07:20
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo
DOS386 wrote:

rugxulo wrote:
And UPX needs more RAM than DJGPP anyways


Don't forget P.A.Q. Laughing


UPX uses a lot more than PAQ. I've noticed it swaps pretty easily and without warning. (Blame C++ or even LZMA, I guess.)

DOS386 wrote:
Wrong, doesn't work. I did test.
rugxulo wrote:
With CWSDPMI ?????


YES.


Even latest r5 2008 RC1? Then report it as a bug! Wink

DOS386 wrote:

rugxulo wrote:
Have you really confirmed this personally? And I'm pretty sure Vista does NOT swap.


YES. Try to kick pagefile.sys Idea


I meant DOS/DPMI swapping under Windows. Does it? I don't think so.

rugxulo wrote:
FASM doesn't need it, only FASMD does. Or is that what you meant? Wink

DOS386 wrote:

Testing on DOS would have revealed the truth.


I do use it in real DOS. It doesn't need DPMI for raw use (unreal / flat real / whatever). Besides, I use the Win32 version (actually, DOS/Win32 hybrid) under HX, so it runs anywhere. Wink

DOS386 wrote:

rugxulo wrote:
In what way? Sure, some of the links don't work, but most of them do. DJ is pretty vigilant (if not 100%). He hasn't abandoned the site (or DJGPP) by any means.


* Does the BUGZILLA work for you ? OK, maybe it's just me, I got banned for all my rude posts on DGJPP Laughing
* Docs are outdated
* ZIP PACKER still defaults to XP ... no final decision between DOS and W7 yet Laughing
* OpenDOS advertised ... but nobody uses it anymore, and no EDR-DOS


He knows about XP and OpenDOS, just doesn't care about such minor things. Docs are obviously extremely outdated, but without anything better to replace 'em, I guess they'll have to stay. Bugzilla? Never use it, so I can't say. (It's pretty stable anyways, let's be honest.)

EDIT: Man, quoting a quote and responding is very confusing. I'm not sure I nested it correctly. Ah, screw it. Razz
Post 19 Feb 2009, 07:40
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
rugxulo wrote:
UPX uses a lot more than PAQ. I've noticed it swaps pretty easily and without warning.


Works fine for me with HDPMI32 so you are probably wrong ... I'll test the minimum ASAP Idea

Quote:
Even latest r5 2008 RC1? Then report it as a bug!


Need a working BUGZILLA Idea

Quote:
I meant DOS/DPMI swapping under Windows. Does it? I don't think so.


There is no "DOS/DPMI swapping under Windows" , just one memory manager and it swaps.

Quote:
It doesn't need DPMI for raw use (unreal / flat real / whatever)


1.67.32

Quote:
Besides, I use the Win32 version (actually, DOS/Win32 hybrid) under HX, so it runs anywhere.


Smile

rugxulo wrote:
He knows about XP and OpenDOS, just doesn't care about such minor things.


He doesn't care about OpenDOS anymore.
Post 19 Feb 2009, 07:54
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7784
Location: Kraków, Poland
Tomasz Grysztar
rugxulo wrote:
Tomasz wrote:

I don't want the amount of packages on the server to grow too quickly with all the small mistake fixes.
7-Zip 'em. Or just store the diffs ("diff -Naur 1.66 1.67 > 1.66_1.67.txt") ZIP'd. Or delete all the docs and examples from older versions (since they don't change much anyways).

It's not the space they take that is my problem. It's just that I don't want to keep a file for every little intermediate or failed (buggy) release, especially in times, when I keep updating them few times an hour.
I've corrected the PHP script to display the full time of last update, instead of just day, this should help keeping track (as even when I update version number for each change in core, there are still some updates that don't touch the core, and therefore the version stays the same).
Post 19 Feb 2009, 09:35
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
Rugxulo wrote:

Quote:
just store the diffs ("diff -Naur 1.66 1.67 > 1.66_1.67.txt") ZIP'd.


And what do you expect to happen when unzipping that ^^^ in DOS Crying or Very sad ?

Quote:
delete all the docs and examples from older versions (since they don't change much anyways).


RE-brew old packages ? Confused

Tomasz wrote:

Quote:
I don't want to keep a file for every little intermediate or failed (buggy) release, especially in times, when I keep updating them few times an hour.


Kick out buggy versions and keep the successful ones (22 26 29 32(?)).

Quote:
corrected the PHP script to display the full time of last update, instead of just day


Very good Smile
Post 19 Feb 2009, 09:52
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7784
Location: Kraków, Poland
Tomasz Grysztar
DOS386 wrote:
Kick out buggy versions and keep the successful ones (22 26 29 32(?)).

They anyway all are going to get kicked out of server when the stable release comes. And I don't have any problem with keeping them all for now.
Post 19 Feb 2009, 10:17
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
I had a look at the fixed DOS IDE: it works now, was it the "segment" too small ?

Code:
; Assembly Editor constants

  SEGMENT_LENGTH        = 0C0h
  BLOCK_LENGTH                = 100h * SEGMENT_LENGTH
  SEGMENT_HEADER_LENGTH = 16
  SEGMENT_DATA_LENGTH        = SEGMENT_LENGTH - SEGMENT_HEADER_LENGTH
    


Any chance to get some info about the memory management in the IDE ? There are no comments Neutral

Also, you fixed the "ZERO-char-BUG" in Smile the ASCII table (I had been aware of it for a long time and it was on my ToDo list also Shocked )
Post 20 Feb 2009, 04:03
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7784
Location: Kraków, Poland
Tomasz Grysztar
DOS386 wrote:
I had a look at the fixed DOS IDE: it works now, was it the "segment" too small ?

See assembly editor core documentation.
Post 20 Feb 2009, 06:52
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1901
DOS386
Oh thanks, looks interesting. Smile From 2006-Jan Shocked DOS IDE didn't exist but was planned ?
Post 20 Feb 2009, 07:24
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 7784
Location: Kraków, Poland
Tomasz Grysztar
DOS386 wrote:
DOS IDE didn't exist but was planned ?

Actually its stated in that very post:
Quote:
The core is separated from the main files, because I wrote it with portability in mind, as I wanted to make also DOS and Linux editor controls based on the same core.

At the time I was not sure if I ever actually make DOS version, but later I did. Still, I'm not sure when - or if at all - I start the Linux version.
Post 20 Feb 2009, 07:28
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4, 5  Next

< 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. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.