flat assembler
Message board for the users of flat assembler.
Index
> DOS > Decommenter / Parser issues: where did those NULs come from? Goto page 1, 2, 3 Next |
Author |
|
fasmnewbie 16 May 2014, 00:17
I don't know if this is the correct section to post but I think it is related to FASMW's formatting?
|
|||
16 May 2014, 00:17 |
|
revolution 16 May 2014, 00:19
For those of us that can't run DOS how about you post the compacted file.
But I suspect your problem is that you use SI as both the input and output pointer in START. You will need a separate pointer for your PACK buffer and a separate SIZE value to indicate the new size. Moving to DOS section Last edited by revolution on 16 May 2014, 00:29; edited 1 time in total |
|||
16 May 2014, 00:19 |
|
fasmnewbie 16 May 2014, 00:26
revolution wrote: For those of use that can't run DOS how about you post the compacted file. Last edited by fasmnewbie on 17 May 2014, 05:01; edited 1 time in total |
|||
16 May 2014, 00:26 |
|
revolution 16 May 2014, 00:28
Look at it with a hex editor.
|
|||
16 May 2014, 00:28 |
|
fasmnewbie 16 May 2014, 00:32
Yeah, I am aware of the SI mismatch. A little confusion when I modified this code for posting purposes.
|
|||
16 May 2014, 00:32 |
|
revolution 16 May 2014, 00:35
So your "compacted" output NEWF.asm is 13.67kB and the input m16.asm was only 13.03kB. Even without seeing the files I can tell there is already something wrong with the output file.
What did you see in the hex editor? |
|||
16 May 2014, 00:35 |
|
fasmnewbie 16 May 2014, 00:37
revolution wrote: Look at it with a hex editor. |
|||
16 May 2014, 00:37 |
|
fasmnewbie 16 May 2014, 00:45
revolution wrote: So your "compacted" output NEWF.asm is 13.67kB and the input m16.asm was only 13.03kB. Even without seeing the files I can tell there is already something wrong with the output file. I don't have hex editor. Will download one shortly. I was about to further "compact" it by eliminating blank lines. But this one holding me back. |
|||
16 May 2014, 00:45 |
|
revolution 16 May 2014, 01:05
Do you realise that you are not removing the comments, but rather are just skipping them and leaving whatever bytes are in the output buffer in its place? You are advancing SI past the comments and just leaving a gap of unwritten bytes in the output.
I suggest you use DI as an output pointer and only advance it when you are putting a new byte into the output. But still keep SI as an input pointer. |
|||
16 May 2014, 01:05 |
|
revolution 16 May 2014, 01:07
Also what happens with this line?
Code: text: db 'Here is some text; this is NOT a comment.',13,10,0 ;this is a comment |
|||
16 May 2014, 01:07 |
|
fasmnewbie 16 May 2014, 01:22
revolution
this is the .txt version (output) from the same code. See, no more comments there. Only blank lines at places used to be comments. And that should be readable in FASMW regardless, because they are in pure ASCII format. But I can't see nothing. I'll post my corrections later. Thanks for spotting the bugs. Catch up with u later. Last edited by fasmnewbie on 17 May 2014, 05:01; edited 1 time in total |
|||
16 May 2014, 01:22 |
|
revolution 16 May 2014, 01:28
Here is what I see.
|
||||||||||
16 May 2014, 01:28 |
|
JohnFound 16 May 2014, 04:49
fasmnewbie, NUL characters are invalid character in a text file. Many programs will consider it as a end-of-file marker (including FASM). The fact that some editors ignore it, proofs nothing. It is still invalid. As revolution already said, you have to fix your code.
Notice also the example with the quoted semicolon. |
|||
16 May 2014, 04:49 |
|
revolution 16 May 2014, 05:26
It's worse than just NULs, it is going to be whatever garbage is in the buffer from the last usage. In this case it appears that NTVDM clears the program memory to all zeros before execution, but not all DOSes will do that.
|
|||
16 May 2014, 05:26 |
|
fasmnewbie 16 May 2014, 06:28
@revolution, I don't know what those NULs means. Are they dangerous? I have no idea. I came to know this thing we call ASCII just last night somewhere between half awake and half asleep. I am a self-learner.
@John, ok. I am completely clueless on this characters interpretation. Very new to me. But the code is fixed already. Code: format mz entry start:main SIZE = 14000 ;size of test file "m16.asm" in bytes segment info fn db "newf.asm",0 ;new file with compacted code opf db "m16.asm",0 ;file to be strip off comments buff db SIZE dup(?) ;buffer read from m16.asm pack db SIZE dup(?) ;buffer of compacted file for newf.asm segment start main: push info pop ds push buff ;Copy the content to this buffer push SIZE ;in this size push opf ;From this file call FOPENR ;Open for reading call START ;Start stripping off comments push fn ;newf is the new (target) file call FNEW ;Create new file push pack ;The content of stripped source push SIZE ;The same size push fn ;the new file to be written call FOPENW mov ah,0 ;Pause int 16h mov ah,4ch ;Exit int 21h START: ;----------------------- xor si,si xor di,di next: mov al,[ds:buff+si] cmp al,';' je pck ok: mov byte[ds:pack+di],al cmp si,SIZE je done inc si inc di jmp next pck: inc si mov al,[ds:buff+si] cmp al,0dh je ok cmp al,0ah je ok jmp pck done: ret FNEW: ;----------------------- push bp mov bp,sp mov dx,[bp+4] mov ah,3ch mov cl,0 int 21h pop bp ret FOPENR: ;----------------------- push bp mov bp,sp mov dx,[bp+4] mov al,0 mov ah,3dh int 21h mov bx,ax mov cx,[bp+6] mov dx,[bp+8] mov ah,3fh int 21h mov ah,3eh ;close handle int 21h pop bp ret FOPENW: ;----------------------- push bp mov bp,sp mov dx,[bp+4] mov al,2 mov ah,3dh int 21h mov bx,ax mov cx,[bp+6] mov dx,[bp+8] mov ah,40h int 21h mov ah,3eh ;close handle int 21h pop bp ret Should be able to get rid of all comments off a source file. |
|||
16 May 2014, 06:28 |
|
fasmnewbie 16 May 2014, 06:39
revolution wrote: Also what happens with this line? Any idea how to fix it? This is my first time engaging this kind of problem and using int 21h's file service. Show me some macro skill |
|||
16 May 2014, 06:39 |
|
fasmnewbie 16 May 2014, 06:48
revolution wrote: It's worse than just NULs, it is going to be whatever garbage is in the buffer from the last usage. In this case it appears that NTVDM clears the program memory to all zeros before execution, but not all DOSes will do that. I am just testing some features of int 21h because windoze won't allow me access to some BIOS disk service - for obvious reasons of course |
|||
16 May 2014, 06:48 |
|
revolution 16 May 2014, 06:50
fasmnewbie wrote: Any idea how to fix it? This is my first time engaging this kind of problem and using int 21h's file service. Show me some macro skill |
|||
16 May 2014, 06:50 |
|
revolution 16 May 2014, 06:52
fasmnewbie wrote: I am just testing some features of int 21h because windoze won't allow me access to some BIOS disk service - for obvious reasons of course |
|||
16 May 2014, 06:52 |
|
Goto page 1, 2, 3 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.