One question, what does assign do (except showing a checkbox ;) )?
(No problems under windows)
Posted on 2002-11-12 09:05:32 by scientica
After re-thinking it, I've decided to follow the suggestion to include AsmEdit control in the .exe, now it's more compact. But after several test with CHM files I saw many problems with it, so I've disabled it until I'll find some better way to do it. Well, after those few tries I started to don't like HtmlHelp interface very much. It seems to be very overbloated and buggy. I've wasted only time on it, which I could use to make some other imrovements.

I'll start the debugger project soon, if I have some free time... Well, if anybody could point me to any existing assembly sources for debuggin routines (and I don't mean disassembler, making a "disfasmer" won't be any problem for me ;), but I need some practical info on the Win32 debugging API).

Assign option is to stick compiler to your main file, which will be used for compile and run commands even while you're editing another one.
Posted on 2002-11-12 16:43:18 by Tomasz Grysztar
You're the best Privalov! ;)

Have you seen these tutorials?
- http://spiff.tripnet.se/~iczelion/tut28.html
- http://spiff.tripnet.se/~iczelion/tut29.html
- http://spiff.tripnet.se/~iczelion/tut30.html

The Iczelion tutorials includes much information on Win32 debugging ;)
If you understand pascal-codes (I suppose you do), try this pascal-compiler (with sources) that has an integrated debugger:
http://www.jrsoftware.org/files2/ip015.zip ;)

Are you going to add the debugger to the exe-file too? (maybe that's the most flexible way to do it?)
:) Well, just keep on going man... and note! tell me if you need help! :grin:

Oh.....my english :(

Regards!
Posted on 2002-11-13 00:21:15 by POW
POW: thanks for the IP link ... nice. and your english is ok, dont excuse everytime :grin:

Privalov: you can have a look at z0mbie's tracer in attachment (sanitized version)
Posted on 2002-11-13 01:04:37 by TBD
I downloaded the new GUI version and browsed the source. I know you still have the
command line versions included, but I'd like to know if you'll keep up support for command line
as well as GUI? I like to use my own editor to create files is all.

Now that I think about it, it probably seems foolish to think you would drop the command-line
version considering all the effort you put into modularizing the code base <-> front end. So maybe
this is a slightly obvious question to answer, but I'll ask it anyway. :)

Not to mention this is real open source, so I can change it later if I need to.

No matter what, thanks for your wonderful assembler Privalov.
It's both inspiring and greatly useful!
Posted on 2002-11-13 03:05:39 by jwm
The core of flat assembler (all files in the root of SOURCE directory) is common for all versions, so when I improve the core, all releases are improved. You don't have to worry about it. And the core is written in the way that it's highly portable, for example Ville Turjanmaa (with my support) has made a port for his MenuetOS. And if anybody wants to make some new port, I can give him the full information about OS-abstraction routines that are needed to implement to get fasm working.
Posted on 2002-11-13 04:31:48 by Tomasz Grysztar
What would have been even more portable is to have written FASM in C... so you could assemble x86 on any processor and OS... but I agree it is rare cases and that you are probably more at your ease by using assembly... but the idea of a 100% portable assembler is seducting...
Posted on 2002-11-13 05:05:31 by JCP
Privalov: yeah, basically what I was saying. In fact, MenuetOS is what led me to find FASM in the first place. FASM led me to find this community. I'm not a windows developer, though I have migrated from *nix to Windows XP/Cygwin. I still only use that as an environment for coding other systems.

Readiosys: IMO that defeats the purpose of writing an assembler. Assembly language is typically used nowadays to create new system level code for modern or theoretical systems as well as efficient embedded systems. I'd be willing to bet a small number of people actually recode speed-crucial routines on C-capable operating systems (other than system coders). Of course, most of everyone who also uses C here and other technically incline C people probably do. I also don't talk from experience of being in a professional software company environment, so I might have just put my foot in my mouth (something I've gotten great at with age).

There are already a good number of assemblers written in C that are pretty portable. GNU as and NASM come in mind. The beauty of writing an assembler in assembly language is that the projects that can benefit the most from an assembler will benefit instantly. While one could argue indefinitely on the merits of such projects, they do exist. They exist in theory-heavy systems that don't have any use for C or standard libraries/call mechanisms that writing a program in C would rely on; the kinds of systems that could be revolutionary.

I guess I am more for the speciality camp than the portability camp. After all, time spent on development is way less than the total run time of most software. It's not as if software is disposable kitchenware or toilet paper. Though, this does ignore the competition factor. I am really only referring to free software development. Yeah, I have my own projects that fall under these criteria, so I may be biased. FOh fwell, foot fastes food.


Fanks,
Joseph
Posted on 2002-11-13 05:58:47 by jwm
Joseph,

I understand what you say...
I think the fact that FASM is written in FASM (so in assembly) is a big advantage as it is probably a bit faster...
I have this little regret that FASM is "x86 only", even if it is not a problem, I love there is no OS frontier, but the CPU frontiers are still there and it is a bit regrattable that the programming langage of choice is the cause of that because it restricts a bit the features...
I think FASM is something that could have been programmed by following the ANSI C standard at 100% and then work in virtually any machine around (even and why not Palms ? :grin: ).
It could have been 100% portable but it is "only" (which is most than many) something like 50% portable...
This is not that much important and I don't even care because I won't probably ever write x86 code in something else than an x86 (uhm, mac maybe ?)... but as we were talking about portability I thought it was appropriate to say it in a "theoritical manner".
I don't say Privalov's choice to code it in assembly was bad as he has for sure very good reasons to do so (the best proof is that it works) but that the side effect was it restricted a bit the "universality" of FASM...
Posted on 2002-11-13 06:45:00 by JCP
yeah, I was just offering a counter argument saying how it makes FASM more "portable." I wasn't really disagreeing.. I think we're talking about two different things in fact. MenuetOS is a good example of what I am
talking about. They would have had to write a whole other assembler for their system instead of just using
FASM. I understand your point too, but I just feel that because of the very nature of assembly programming
that it really makes sense to make the assembler in assembly language I feel your pain towards architecture
dependency.. I'll be working to solve that with my projects. Unfortunately, the best thing right now that we
have for completely efficient programming is assembly language.
(I'm talking about 100% efficient, not 99.99, not 80/20)

Yeah, the "unfortunate" line might annoy a few asm programmers here. I don't see how people can consider
programming PCs as fun. ;) But that is another thread/board entirely. :)


I'm sure this question has been asked before: Why is flat assembler called flat assembler? Because
of its creating flat binaries better/easier? Sorry if this is OT or in a FAQ.
Posted on 2002-11-13 07:09:08 by jwm
Hi, there!

Win32 GUI crashed when I compiled this code instead of show a compiler error:

code:
;begin
org 100h
mov di,+*7
int 20h

board db ?
x db ?
y db ?
;end

why this happen?
Posted on 2002-11-13 07:20:03 by Despero
TBD, really nice!

Thanks!
Regards!
Posted on 2002-11-13 08:24:39 by POW
Privalov,

Nice work you're doing. What about inserting a SpAsm-alike .idata builder.

Api's would need to get defined as for example:

stdcall 'Kernel32.dll.Sleep' 1200

And all you'd have to do is parsing the file for Api's and create it on the fly when building.

Of course this eliminates some of the freedom but it increases also some of it's usability. And noone said this should be the default. Just add an option for it in the GUI version and there we go ;)

Regards,
JimmyClif
Posted on 2002-11-13 08:31:49 by JimmyClif
Despero: what Windows version are you using? On my the crash doesn't happen.
Posted on 2002-11-13 09:45:59 by Tomasz Grysztar
Hi Readiosys,
I'm with you about portability of tools (and to short as much as possible the development time required to make them, while keeping them of great quality/usefulness).. but if we think better about the specific case, to do cross-development with FAsm on another CPU you'd need a x86 emulator anyway (otherwise there's no big usefulness in writing code you can't even run and test).
But if you have a x86 emulator, you can run also FAsm under it anyway. ;)

At the end though I think, as you said, that the thing that counts is that FAsm is here anyway, and that Privalov shared it with us. I've supported FAsm since the first time I've been able to use it (thanks to Privalov's commitment to support some features I couldn't live without; and his humbleness that predisposed me to support it even more; and his great skills that meant FAsm not only supported them, but with top quality as well), and I'll always keep on supporting it. I also think that the new FAsm+Integrated Debugger/Editor/Assembler is gonna make x86 know something they've been missing for too long.. then really no more excuses for keeping on using MASM/TASM/NASM/OrgAsm :grin:

Posted on 2002-11-13 11:22:39 by Maverick
I'm using Win ME.
Posted on 2002-11-13 19:55:46 by Despero
Originally posted by Maverick
I'm with you about portability of tools (and to short as much as possible the development time required to make them, while keeping them of great quality/usefulness).. but if we think better about the specific case, to do cross-development with FAsm on another CPU you'd need a x86 emulator anyway (otherwise there's no big usefulness in writing code you can't even run and test).
But if you have a x86 emulator, you can run also FAsm under it anyway. ;)


You are right about the emulator, but an emulator isn't always of big confort...
For example, if you have a macintosh environment you would probably want to work on your code in your dev environment from the Mac and not from the PC...
Also, I have experienced cross compiling and assemblying when I did some work on the SNES (aka Super Nintendo:65c816) console...
We used some free assemblers for PC... we were bound by some uncompleted/undocumented assembler issues while some very good assemblers were available for the Amiga... If we had had the full ANSI compliant source, we could have fixed some bugs without much problems, and rewriting the whole assembler was a bit too much for just a 30 sec intro. It is probably something that changed my views about portability, especially in development tools...

At the end though I think, as you said, that the thing that counts is that FAsm is here anyway, and that Privalov shared it with us. I've supported FAsm since the first time I've been able to use it (thanks to Privalov's commitment to support some features I couldn't live without; and his humbleness that predisposed me to support it even more; and his great skills that meant FAsm not only supported them, but with top quality as well), and I'll always keep on supporting it. I also think that the new FAsm+Integrated Debugger/Editor/Assembler is gonna make x86 know something they've been missing for too long.. then really no more excuses for keeping on using MASM/TASM/NASM/OrgAsm :grin:


Joseph made a good point by saying that C compilers does not always exist in all OSes, especially the one currently in development. Full portability is something virtually inachievable and FASM already has a very good one since it is able to assemble itself and run under the two most popular x86 OSes, Windows and Linux... so it is not much important.

Most compilers C sources I have seen are unreadable... FASM one, while in assembly, is quite readable even if it is spaghetti code, it is propably easier to follow than a gnu compiler or similar :)
It is why I admire people like you and Privalov able to make their own development tools since writing maintenable and well architectured langage parsers must be something quite hard...
Posted on 2002-11-14 01:29:08 by JCP

I'm using Win ME.

Me too :)
But It didn't crash when I compiled the code...
Posted on 2002-11-14 03:24:21 by scientica
Oh, now I see. We shouldn't have been copying the "code:" label, only the instructions below. I've got the crash and fixed it then. That was a minor mistake when improving parser to be less strict. All releases are updated with this fix, no other important changes.
Apart of this, the 1.41 should be really the much less buggy than previous version because I've scanned it for syntax-related bugs (and fixed all) while writing the new documentation (which describes currently every possible syntax option, if some feature is not documented, it's probably a buf ;)).
Posted on 2002-11-14 05:28:52 by Tomasz Grysztar
Hi Privalov,

when i defined dword data like this: dd 'Pray'
I got db 'P','r','a','y' in hexeditor. It's should be 'y','a','r','P' like Masm does:(
(It's doesn't swap byte) and in macro like the following

macro foo name
{
local b
b equ '#name#' (to make string var)
}

Doesn't work too, why?
Posted on 2002-11-15 01:54:13 by Bi_Dark