Index
> Main > flat assembler 1.67.3xGoto page Previous 1, 2, 3, 4, 5 Next |
| Author |
|
|
DOS386 14 Feb 2009, 07:55
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) Secret update ? So Code: mov eax, $FFFF'FFFF will work now ? 
Quote: possibly I should state it more clearly in the documentation draft? No big need IMHO  _________________ Bug Nr.: 12345 Title: Hello World program compiles to 100 KB !!! Status: Closed: NOT a Bug |
|||
14 Feb 2009, 07:55 |
|
|
DOS386 18 Feb 2009, 07:17
> That would not be a good idea
oops ... 
> 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 
I see that you fixed the thread subject also |
|||
|
18 Feb 2009, 07:17 |
|
|
Tomasz Grysztar 18 Feb 2009, 19:20
DOS386 wrote: >+ passes limit Oops, I forgot about passes limit setting. Even in fasmw. 
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. |
|||
|
18 Feb 2009, 19:20 |
|
|
rugxulo 18 Feb 2009, 21:42
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!  |
|||
|
18 Feb 2009, 21:42 |
|
|
Tomasz Grysztar 18 Feb 2009, 22:40
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.
|
|||
|
18 Feb 2009, 22:40 |
|
|
DOS386 19 Feb 2009, 06:20
rugxulo wrote: Win32 download doesn't have the latest changes (e.g. FASMD.ASM is still dated the 13th). Very minor 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 ? 
Quote: I also tried using *nix LFs 
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. 
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 WOW
> > passes limit > forgot about passes limit setting. Even in fasmw.
> 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
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 
> 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. |
|||
|
19 Feb 2009, 06:20 |
|
|
rugxulo 19 Feb 2009, 06:30
revolution wrote:
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. 
Tomasz wrote:
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:
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. 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.
P.S. Glad .INI file colors (supposedly? heh) works. Now I don't have to manually patch FASMD every single time.
EDIT: Heh, DOS386 just barely beat me with his reply! |
|||
|
19 Feb 2009, 06:30 |
|
|
DOS386 19 Feb 2009, 06:49
rugxulo wrote: I have yet to see any swapping Get DGJPP
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
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 |
|||
|
19 Feb 2009, 06:49 |
|
|
rugxulo 19 Feb 2009, 06:58
DOS386 wrote:
I meant with FASM I've never noticed it. (And UPX needs more RAM than DJGPP anyways.) DOS386 wrote:
With CWSDPMI ????? DOS386 wrote:
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:
FASM doesn't need it, only FASMD does. Or is that what you meant?
DOS386 wrote:
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:
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. |
|||
|
19 Feb 2009, 06:58 |
|
|
DOS386 19 Feb 2009, 07:20
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.
Quote:
YES. Quote: Have you really confirmed this personally? YES. Try to kick pagefile.sys
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? 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
* Docs are outdated * ZIP PACKER still defaults to XP ... no final decision between DOS and W7 yet
* OpenDOS advertised ... but nobody uses it anymore, and no EDR-DOS |
|||
|
19 Feb 2009, 07:20 |
|
|
rugxulo 19 Feb 2009, 07:40
DOS386 wrote:
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. Even latest r5 2008 RC1? Then report it as a bug!
DOS386 wrote:
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? 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.
DOS386 wrote:
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. |
|||
|
19 Feb 2009, 07:40 |
|
|
DOS386 19 Feb 2009, 07:54
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
Quote: Even latest r5 2008 RC1? Then report it as a bug! Need a working BUGZILLA
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.
rugxulo wrote: He knows about XP and OpenDOS, just doesn't care about such minor things. He doesn't care about OpenDOS anymore. |
|||
|
19 Feb 2009, 07:54 |
|
|
Tomasz Grysztar 19 Feb 2009, 09:35
rugxulo wrote:
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). |
|||
|
19 Feb 2009, 09:35 |
|
|
DOS386 19 Feb 2009, 09:52
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 ?
Quote: delete all the docs and examples from older versions (since they don't change much anyways). RE-brew old packages ?
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 |
|||
|
19 Feb 2009, 09:52 |
|
|
Tomasz Grysztar 19 Feb 2009, 10:17
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. |
|||
|
19 Feb 2009, 10:17 |
|
|
DOS386 20 Feb 2009, 04:03
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 
Also, you fixed the "ZERO-char-BUG" in the ASCII table (I had been aware of it for a long time and it was on my ToDo list also  ) |
|||
|
20 Feb 2009, 04:03 |
|
|
Tomasz Grysztar 20 Feb 2009, 06:52
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. |
|||
|
20 Feb 2009, 06:52 |
|
|
DOS386 20 Feb 2009, 07:24
Oh thanks, looks interesting.
From 2006-Jan DOS IDE didn't exist but was planned ? |
|||
|
20 Feb 2009, 07:24 |
|
|
Tomasz Grysztar 20 Feb 2009, 07:28
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. |
|||
|
20 Feb 2009, 07:28 |
|
| Goto page Previous 1, 2, 3, 4, 5 Next < Last Thread | Next Thread > |
Forum Rules:
|