Index
> Compiler Internals > Major architectural flaw in FASM?Goto page 1, 2 Next |
| Author |
|
|
comrade 29 Nov 2003, 22:21
Why?
|
|||
29 Nov 2003, 22:21 |
|
|
Betov 29 Nov 2003, 22:41
Not stoping at the first encounted error would be a major design flaw, art. It seems you have no idea about how encoders'parsers work
 Look at what happend with Languages that do provide multiple errors checking. In many case you may got xxxxx error Messages that may as well be generated by one single real error. Not wishable at all.
Also, with the actual Assemblers speeds, you should not write pages before firing a run (or if you can have 45 errors in five lines, you'd better...). Betov. |
|||
|
29 Nov 2003, 22:41 |
|
|
Tomasz Grysztar 30 Nov 2003, 00:13
Betov: thanks. You have said exactly what I'd have to say. That's what I've called the "error avalanche" in the other thread.
|
|||
|
30 Nov 2003, 00:13 |
|
|
art_sands 30 Nov 2003, 07:04
Betov
You're right. FASM dont need to implement it directly inside it. An ide could implement a separate parser to find out these vulnerabilities. If you're worried about the assembler not stopping, then check out the example I gave. "Could not generate executable.". That surely indicates the assembler stopped producing the file, but the parser continued. I didn't know adding this feature to FASM's architecture would cause an "error avalanche". About the "..." you've put in, that was only an example. How about when you were a kid. Were you born with all the knowledge you have. I hope you made mistakes too as bad as "45 errors in 5 lines". Does that mean you stopped living? I may not know compiler design yet, but you sure look like you don't know english. And if you think this situation is not practical, then what use is your knowledge. The situation is practical and I agree to Privalov's answer in the other thread. Please don't take this to heart. I only want FASM to get better and better. Nothin else. Regards, Art |
|||
|
30 Nov 2003, 07:04 |
|
|
Tomasz Grysztar 30 Nov 2003, 08:58
You mean the "code cannot be generated" message, but this one is an other kind of error - it happens when there were no other errors during the compilation, but assembler failed to resolve all the symbols in the limit of passes it has (currently this limit is 65536). If there was no any limit, the assembler would just hang (or run out of memory) on some unresolvable codes, like:
Code: rb alpha+1 alpha = $ |
|||
|
30 Nov 2003, 08:58 |
|
|
art_sands 30 Nov 2003, 09:38
Hi Privalov,
I hope I am not bugging you. It's only that I want FASM to eventually become the best assembler. I've already posted in several forums that FASM is the future of asm, and that a revolution is coming. You're the man. FASM = Future ASM If in any case, I might have annoyed you, I'm terribly sorry and humbly apologize. If you don't mind, please could you redirect me to some compiler internals resources, so that I could enlighten myself about them. Thanks. Regards, Art |
|||
|
30 Nov 2003, 09:38 |
|
|
vid 30 Nov 2003, 11:48
last internals documentation released i know is included in fresh.
privalov: i think after finishing 1.50 you should take a rest (?) and write new internals doc. |
|||
|
30 Nov 2003, 11:48 |
|
|
scientica 30 Nov 2003, 13:16
art_sands wrote: I hope I am not bugging you. It's only that I want FASM to eventually become the best assembler. I've already posted in several forums that FASM is the future of asm, and that a revolution is coming. You're the man. fasm is already (IMO at least) the best asssembler in the world (but some how it keeps getting better and better with every new version )
fasm = flat assembler If it's one thing I don't like it's an error avalance. 45 errors? The you should have know how many days (lost cound of compiler errors after about half a day) I spend tracking down errors while "translating" an old project from masm to fasm syntax, the thing is even if I'd seen like 300 errors a head I wouldn't have been of any help, since after fixing (or beliving so  ) I had to check the pice nearest to the error for any other hiden errors (like obivous mis-translations of var <-> [var], etc). Tthose times when I tried to fix 10-15 bugs at a time it often resulted in other errors, or spedning mpre time figuring out the new line number of the error after moidyfing/adding/removing and number of lines above, it would simple have been faster to fix the error recompile and get the erroe line directly._________________ ... a professor saying: "use this proprietary software to learn computer science" is the same as English professor handing you a copy of Shakespeare and saying: "use this book to learn Shakespeare without opening the book itself. - Bradley Kuhn |
|||
|
30 Nov 2003, 13:16 |
|
|
Tommy 30 Nov 2003, 13:43
I fully agree Scientica. FASM is the best assembler out there, and its error-tracking system is perfect. IMHO showing one error - if any - is the best way to do it, else you end up with hundreds of errors where many of them may be caused of another etc... Privalov, keep it the way it is!
I love it! 
(Note! not to be selfish, I'm only sharing my opinions... I think it's good to discuss such questions because then we're getting new ideas and getting knowledge to what's the best way to doing things..  )
Got to go! Regards, Tommy |
|||
|
30 Nov 2003, 13:43 |
|
|
art_sands 30 Nov 2003, 14:35
I like hitting the sweet spot.
And it may have angered some people, but hey people, this is the way people learn.
I'm no god. You're no god. Everybody is not god. Nobody is god. Everybody learns and everybody should help everybody else learn. Hope everybody enjoyed what everybody should have because I wanted everybody to learn what everybody should have learnt. I hope everybody likes this post as much as I like 'everybody'. 
Ok too much everybody. I'll cut the crap.
Just Kidding Folks.
Regards, Art |
|||
|
30 Nov 2003, 14:35 |
|
|
Mac2004 15 Dec 2003, 14:17
I have been using assembler for several years and during that time i have used many different assemblers. I think that an option to save preprocessor results on disk is useful for debugging purposes.
If you get many errors at the same time you'll need assembly expererince to make a difference which errors are real and which are not. This will become available only through trial and error. Of course integrated IDE pre-processor could do the trick. regards, mac2004 |
|||
|
15 Dec 2003, 14:17 |
|
|
Tomasz Grysztar 15 Dec 2003, 16:33
Put those two macros at the beginning of the fasm's source and recompile it to get the version that converts the preprocessed source back into a text form (though an ugly one) and stores it in the PREPROCE.DAT file:
Code: macro parser colon { parser: jmp @f _preprocessed db 'PREPROCE.DAT',0 @@: mov edx,_preprocessed call create mov esi,[memory_start] .convert_preprocessed_line: mov edi,[source_start] cmp esi,edi jae .preprocessed_source_ok add esi,16 xor dl,dl .convert_instruction: lodsb cmp al,1Ah je .copy_symbol cmp al,22h je .copy_symbol or al,al jz .instruction_converted stosb cmp al,3Bh je .space_ok xor dl,dl jmp .convert_instruction .copy_symbol: or dl,dl jz .space_ok mov byte [edi],20h inc edi .space_ok: cmp al,22h je .quoted lodsb movzx ecx,al cmp byte [esi+ecx-5],7Bh je .macro_directive cmp byte [esi+ecx-5],7Ch je .struc_directive rep movsb or dl,-1 jmp .convert_instruction .macro_directive: mov eax,'macr' stosd mov al,'o' stosb .macro_directive_ok: add esi,ecx or dl,-1 jmp .convert_instruction .struc_directive: mov eax,'stru' stosd mov al,'c' stosb jmp .macro_directive_ok .quoted: mov al,27h stosb lodsd mov ecx,eax jecxz .quoted_copied .copy_quoted: lodsb stosb cmp al,27h jne .quote_ok stosb .quote_ok: loop .copy_quoted .quoted_copied: mov al,27h stosb or dl,-1 jmp .convert_instruction .instruction_converted: mov ax,0A0Dh stosw mov ecx,edi mov edx,[source_start] sub ecx,edx call write jmp .convert_preprocessed_line .preprocessed_source_ok: call close } macro define_macro colon { define_macro: mov al,7Bh add al,ah mov [esi-5],al } Last edited by Tomasz Grysztar on 20 Dec 2003, 18:44; edited 1 time in total |
|||
|
15 Dec 2003, 16:33 |
|
|
JohnFound 15 Dec 2003, 17:55
 Definitely, masterpeace!
Regards |
|||
|
15 Dec 2003, 17:55 |
|
|
rob.rice 20 Dec 2003, 18:33
art_sands wrote: Help needed, You have the source code and the assembler why not change it yourself IN the open source world If some thing realy bothers us or if we realy want something changed we do it ower selves and send it to the maintaner if she/he likes it it becomes part of the program there are some things I would like to see in Fasm and have ben waiting for the internals doc so I can understand how it works |
|||
|
20 Dec 2003, 18:33 |
|
|
Ralph 05 Jan 2004, 02:22
Just to throw my own two cents in here, I have never been unsatisfied with any assemblers error output. 95% of the time it's a typo or I started an instruction, got off-track and forgot to finish it. You can go days without running into an assembler level error if you just make sure you type your labels correctly and don't try shit like mov eax,al. The real problem is making bochs shut up because your return pointer got lost somewhere and your code is running amok.
Besides, who really writes more than around 50 lines at a time without assembling the code at least once? |
|||
|
05 Jan 2004, 02:22 |
|
|
Randall Hyde 30 Jan 2004, 18:44
Although the cascading error problem can be a real pain, I prefer a language translator that, at least, attempts to recover and continue processing. True, all errors beyond the first one may be bogus (and caused by the first error); but after you've used the tool for a little bit you get a pretty good idea of whether or not the following errors are related to the first one or not (e.g., if you start seeing successive line numbers on error messages, chances are pretty good you're suffering from the cascading error problem; OTOH, if you see two error messages with line numbers widely separated, then chances are pretty good that the first error is not the cause of the second).
Yes, error recovery is a difficult process. Especially if you want to eliminate as many cascading errors as possible. But for professionals, being able to correct multiple typos at once in a source file can be a real time saver. As to the comment about "nobody ever writes more than 50 lines of code without assembling the file" -- that's probably a direct response to the fact that the assembler only reports one error at a time and you've conditioned yourself to always reassemble on a frequent basis. Rest assured, this is not common practice with *all* tools out there. As for the "100's of errors" problem. You can always do like MASM or TASM does and abort the assembler after n errors have been displayed (usually, you can set this value from the command line). Way back in the days of UCSD Pascal, I remember them having a "student mode" that aborted immediately after the first error (and left you in the editor with the cursor on the offending line). Most students turned this feature off after a few weeks (i.e., after they discovered how to disable it) because they found they were *far* more productive correcting several errors after a compilation rather than one error per compilation. In assembly language, but especially for a traditional assembler (that can easily resync the parser by skipping to the end of the current line), error recovery is a whole lot easier than in most HLLs, so it makes sense to do this recovery if at all possible. If some people really don't like seeing more than one error at a time, then do like MASM/TASM does and provide a command line parameter to specify the maximum number of errors before assembly aborts (and they can set the maximum to one). Cheers, Randy Hyde |
|||
|
30 Jan 2004, 18:44 |
|
|
vid 30 Jan 2004, 20:09
another important aspect you didnt mention is coding such error system. It will require Privalov to spend very lot of time upon it, probably rewrite 70% of stuff, and will make source much more complicated and hardly modifiable. I dont think it is worth of effort it may (!) bring.
|
|||
|
30 Jan 2004, 20:09 |
|
|
ronware 30 Jan 2004, 20:25
vid wrote: another important aspect you didnt mention is coding such error system. It will require Privalov to spend very lot of time upon it, probably rewrite 70% of stuff, and will make source much more complicated and hardly modifiable. I dont think it is worth of effort it may (!) bring. I agree. I would rather he make the existing errors more meaningful. I don't have an example immediately, but there are plenty of times I get an error and it is not clear what the problem actually is. But the most important to me is that the assembler work correctly and I prefer features added to working on error messages. |
|||
|
30 Jan 2004, 20:25 |
|
|
pelaillo 30 Jan 2004, 21:00
If you use a good code editor, you could reduce syntax errors to a minimum.
Other than for syntax errors I see little help on an errors' list. You keep your attention in one error at a time, otherwise the risk for remaining bugs are high. |
|||
|
30 Jan 2004, 21:00 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|