Hi:

Tom Tobias had mentioned some improvements for assembler.

I though me might as well start a new thread to discuss what would be the best format for a new assembler.

I don't know anything about Wirth, so if you could give me some example code that would be great.

My concern was that most of my labels are .l1:, .l2:, .l3:,... Labels that have no meaning but are just there for flow control. If I could design the assembler so that this was uneeded that would be great.

I love risc, but Intel isn't risc. I can't see getting rid of xor since it is still a usefull instruction. It also does save space.
xor eax,eax saves about 4 bytes over
mov eax,0

I agree pushing and popping does make debugging a pain and clutters code.

To me the biggest thing is how the language is layed out. If anybody has some ideas, please let me know. Let's discuss the best format for an assembler language.

Well, I saw (and used) many assemblers in my work, since 1984 year. I began with manual assembling (machine code), through "microassembler" and "macroassembler" for 6502, to x86, where I began with MASM, then TASM, but I never like them so much. After that I find another TASM (not from Borland, but from firm "Speedware") and with my own IDE it was suitable for me for many years. Unfortunately it is discontinued and for modern computers absolutely useless, so, when I decided to learn something about Windows asm programming, I began to play again with TASM, MASM, NASM, SpAsm, etc. But I found the best I wish in FASM. It is the best assemblers I ever saw. And the most exciting is that Privalov succeed to make it even better with every new version.
Believe me, there is no need for new assembler. There is a need for user applications written in assembler. (whatever assembler)

Well, after this emotional post, don't get me wrong - if you want to write assembler - OK write it. It is excelent way for education. But if you want to write valuable product, that people will use, you should know that it is a task for years, not for months.

Regards.

John is absolutely correct: Fasm is the best assembler available. My crude suggestions were meant to stimulate discussion of a SUBSET of intel instructions that could be used to build everything from OS to spread sheet to USB flash memory boot device, and everything in between.
Intel, gomer73, you are correct, is certainly NOT a risc machine, it is the antithesis of risc, a cisc machine, but why shouldn't one, just starting out to make something NEW, try a completely different approach, from those that have already been done. Bogdan is making his own assembler, one that we hope will resemble beloved old TASM, and now gomer73 will make his own, which will be different, and a standard bearer, meantime, 13 year old Joachim is still using NASM, and Randy Hyde and Kip Irvine and lots of others, are still touting MASM, so, how many assemblers do we need any way? John is correct, in my opinion, FASM is the best, and maybe John is also correct, FASM is the ONLY assembler we need....? My suggestion was only meant to stimulate discussion about MINIMALIST program design, i.e. the opposite of what most people are thinking, today. If you know music, then think of John Cage, or Arvo Part, rather than Sibelius or Rachmaninoff (both also extremely skillful composers). According to this idea, one would CONVERT, or some would argue, SUBVERT, the Intel architecture into a "RISC" like subset. In other words, application programmers, using this minimalist design, would be constrained to employ only a paucity of the vast quantity of instructions available. Such a limitation has a price. Not only are some favorite expressions (favorite, even if incorrect, such as xor eax, eax) unavailable, but code becomes much bulkier, and runs much slower. Horrors. Awful. Shameful. A disgrace!!! Yegads, waiter there's a mouse in the house. But, what one LOSES in terms of execution speed, one GAINS in program development, AND THAT TIME, unlike execution time, EQUALS MONEY... MONEY. Worth repeating. WHy is it worth repeating? Because some people need money!!! Now, if one is building a device driver to guide a rover on the surface of Mars, seeking confirmation of water, then, perhaps, (PERHAPS because the Americans still haven't learned even the metric system, let alone assembly language programming) execution speed is important, though I will argue, in that setting, that the x86 architecture is inappropriate anyway, so, what IS important?? (MONEY!~!!!!!) LOts of it, ....
1. Start over. New thinking. New design. Can't change the hardware, it is universal. Sorry, like to change it. but can't .
2. REgisters: wow, what everyone dreams of : LOTS of registers. Well, now we have them. Lots. Not just eax, etc, CACHE memory, on chip, lots of it. Just like registers. No need to waste bus cycles going out to fetch data in offchip memory, when we have tens of k32bitwords (formerly called "bytes") sitting around getting dusty in cache. When we say, oh, I wish the INtel archtecture had lots of registers, like the Sparc or the MIPS, or even the old 68020, what we mean is: I wish we could have FAST access to a variable, stored in a location that did not waste clock cycles fetching, cluttering the pipeline, etc. Guess what: We have tons of such locations. We don't call them REGISTERS. We call it cache memory. WHOLE programs can reside in cache. Forget about registers. Thing of the past.
3. Memory: probably the single most important design constraint for the last 6 decades has been the TERRIBLY expensive cost of memory. Guess what. Now it is free, or nearly so. As much as you want. You want a gigabyte, you got it. When I started out, my first 128 RAM, (no, not 128K, just 128, replacing all those flip flops), seemed like a miracle. But, for SCORES of years, i.e. 60 years, people struggled MIGHTILY, to figure out clever ways to SAVE MEMORY. Lots of Patents and Ph.D. theses have been granted for clever methods to SAVE MEMORY. Whole books have been written on the subject. For more than half a century, memory cost was prohibitive, and the single most important factor in program design and execution. THE INTEL ARCHITECTURE IS BASED ON A PREMISE OF EXPENSIVE MEMORY. Forget it. no need to save memory, today. Waste it. you've got a ton. USE MEMORY to create EASE OF UNDERSTANDING OF PROGRAM DESIGN. No more bits, and bytes, and this and that. JUST ONE DATA SIZE, just one addressing mode. Sure, Intel has lots of modes, and many ARE FAR MORE EFFICIENT, than direct mode. BUT AT WHAT PRICE???? READABILITY IS THE KEY to developing a genuinely new, and USEFUL assembler, one that is different, and incompatible with every piece of code written to date. Programs that assemble well with MASM, TASM, FASM, NASM, or any other existing assembler, WILL NOT ASSEMBLE with this minimalist design. (That's why it's called, NEW. It's different.)
Gomer73 asked about WIRTH.
Niklas Wirth. Mathematician, Professor of computer science in Switzerland, perhaps Zurich. Brilliant. Genius. (Somebody like Tomasz.), Wirth was the Inventor of Pascal and Modula. Well, the sun is setting here in USA. Time to move on to the next task at hand. Hope this was useful, or at least, controversial...... regards, tom tobias nbri@mail.china.com

First off I would like to say for what FASM tries to do it is very good. It is a very good file assembler. I like fasm best, not for its features but for its simplicity and speed. I can slap something together and compile it quickly with fasm.

However, to say we need no other assembler besides fasm I think is very limiting, we need to expand our horizons. Using other languages helps me to see where improvements can be made.

1.) I would like autopopulating of structures. So that if I start typing a structure that is say RECT, it will give me a list of members as soon as I hit the period. I would also like this to be done with assembler commands so that I know all my addressing modes.

2.) I would like to address data without labeling it. For example, I would like to be able to code the following:
mov eax,"This is a test"
where eax is located in a data area and eax is set to a pointer of that data.

3.) Real time compiling. Why does everything nowadays have to be unix compatible. I don't necessarily want to be able to compile a file written by any text editor, not if not doing so gives me benefits. Why can't code be compiled as you are typing it? Right now the answer is because we are stuck in traditional assembler mode thinking. You can do this even if you use labels. The label area just doesn't get compiled until the label actually exists.

4.) I would like to have function calls much like c where all the parameter can be put on one line. Invoke kind of does this, but I also want support for setting the registers. I also want my list so that as soon as I type the function name, I can see what parameters I need.

Even fasm can be improved. It should give warnings when access a word pointer as a byte, not stop compiling. Also, it should not stop compiling when it hits the first error. It should show you all your errors so that you can fix them all at once.

For Tom:
Sorry Tom, I now definitely do not see your point of view. The only way I could see what you are saying being of benefit is if a person was designing a new processor. In that case it makes sense. However, it does not make any sense to restrict yourself when the processor supports more instructions. To me any person who can't tell that xor eax,eax is zeroing out eax wouldn't be able to understand the rest of your code. Also you said you didn't think we should use the FPU. How would this make code easier to read? Not only would it be slower for SIN and other of those functions, but the code would be much harder to understand what it is doing. Even the stack has it benefits. If a routine is can be called by different threads, the only way I know of making sure you are not overwriting your variables is by putting them on the stack.
I think if we create an assembler that is designed like an IDE like other programming languages you would change your thinking. Right now it seems everybody is so unix oriented in their thinking it is hard to break the mold.

Menuet tries to break that mode of thinking and is commended for it. However, I won't be programming in Menuet because I see it is stuck in the Microsoft thinking. It still requires the program to redraw it's window everytime every time something invalidates the window. Why should this be the case. Why should the program constantly have to tell the OS the contents of its window? The OS should remember what the program has told it are the contents of the window and redraw it from there. The disadvantages of this are clearly seen with color demo II. Look at how slow the redraw is. On my computer I can redraw the entire screen about 50 times a second. It takes about .5-1 second for color demo II to redraw. The reason for this is because it is not just redrawing the graphics, but it is re-running all the code used to create those graphics.

It is not my intent to offend, but to promote thinking outside of our current limitations.

...Gomer73

Hi, Gomer73.

I was prepared long post as a respond, but something crashed in my browser and I lost it. I am too lazy to rewrite it from the begining, so I will try to say it shortly:

Some of your ideas are in generally reasonable and they are realized (or they are in To-Do list) in Fresh project. (Actually Fresh is FASM port to advanced GUI environment).

Other of your ideas, tend to reflect your personal programming style and some HLL ideas, that is OK of course, but you can't expect that everyone will have the same style of programming/thinking.

So, I wish you good luck. One more good assembler is a good thing in generally. Of course you know that such project is long (very long) term project.

Regards.

I hate when the browser crashes after you've put a lot of work into writing a response.

That's cool about the FASM thing, I would think they would start implementing the structure thing first.

HAL I think is probably on the right track. It is interesting to note that he is now starting to use FASM to do his compiling. When I was originally researching assemblers I didn't even consider this one because his mov commands are reverse of everybody else's. I think his might be too much high level for me. It almost looks like c with inline assembly language.

Masm and Tasm might actually even do what I want. But none of the three give the source code, so I couldn't convert to my OS.

I still don't understand why you think an assembler is such a complicated thing to make. It seems like a pretty simple process to me.

The steps are:
1.) Develop a single line assembler(I think you can even get this from olydebug)
2.) Add ability for labels so that your can assemble multiple lines
3.) Add more features

I think you are probably thinking about point 3, that is the thing that will take a long time. But it is only as complicated/time consuming as you make it. I am not going for TASM/MASM/FASM compatibility. I am not designing it to assemble windows programs or DOS exe programs.

Parts 1 & 2 shouldn't take too much time.

If you mean HLA, IMHO, you are totaly wrong. I tryed this ideas 15 years ago (for Apple II) but after some research and developement I reject them, because I realized that this track is wrong. It is very long and hot issue to discuss it here. And of course you may have your opinion.



Well, processes that seems pretty simple are most dangerous.
Seriously, every project that is intended to be usefull for more people than his author, tend to need a lots more time than the author suppose at the start. Of course you can write simple toy, able to compile something for a month, but to polish it and to make it valuable assembler is another deal. Trust me, you will need years.
This rule is not only for assemblers, nor for assembly written programs, it is universal programming rule that is language independent and I never saw any exception from it.
I don't want to discourage you. Even if you discard the project at the middle of the way, it can be great education for you, so go for it.

Regards

This is a really cool one

Years ago, the desire for this feature alone made me write an assembler from scratch!
[/quote]

[quote="0x4e71"]


I know one assembler whith this feature is called 'octasm' and you can downlad it in "Programmers Heaven"
And writing a god assembler is not as easy as you think even if you are a experienced programmer it takes years to write such a program.
But of course you can do a very simple assembler in some months.

Sorry, may be it's offtopic, but..
What's wrong with FASM? Just simple macro


===========================
FASM = Future ASM

Yes, problems like this are easy solvable with FASM macro engine. I simply can't understand people prefering such macroses buryed inside the assembler.

Regards.

The strongest characteristic of fasm is the rigorously defined and logical syntax.
You know, Privalov is a Mathematician.
He's too strict in adding features that could derive in unexpected results or dualities and language directives are clean, well defined and powerful.

This goes far beyond implementation facts, features and processor characteristics. You even can change/adapt x86.inc file to fit another instruction set or do a bigger modification to it and the language does not change.

If you want to produce an assembler for learning/excercising is good but there are other priorities where you can excercise: write nice apps for MenuetOS and SolOS using fasm.
Otherwise you will spend years coding to arrive at today's fasm level.*

Best Regards,
pelaillo

* If you are wise, brilliant and patient enough...

This a long reply, sorry in advance for the length.

I think fasm is an awesome assembler.
If I could understand macros, I would use them. Like I said before I don't know how fasm works. I am a documentation based person if I am given the documentation as to how something should work, I can usually do some pretty good things with it. I don't understand macros and I don't feel like reading source code or undocumented macros to figure out how they work.

I think you have to realize I am relatively new to FASM. It is easy to understand how something works if you have been with it from the early stages where it was quite simple. Then when it got more complicated your learned gained in complexity. To try to learn how it works at its current complexity with no documentation is very tough.

I don't even understand the macro S.T.A.S. wrote. Your macro doesn't even work if you do it twice in a row.

Regardless though, it is my opinion that an assembler is almost useless without a debugger. It wastes too much of your time trying to fix programs if you don't have a debugger. I don't know of any debuggers that work with fasm source code(probably because there are no files besides the executeables that fasm generates). Even if there are, I need the debugger to work with my OS. I also would like to incorporate debugger and assembler in the same program so that it is similar to DOS debug. Probably a lot of confusion exists because most have never used debug.exe.

Ollydebug kind of does this, but it doesn't allow you to create new programs, plus I want to walk the source file much like Visual C++ allows you to do.

I don't have any desire to write a God assembler. To me FASM is a God assembler. It tries to do everything. It supports Linux, MenuetOS, dos and windows file types, and macros that can almost do anything. I just want an assembler/debugger that allows me the same ease of programming as Visual C++. Some things just cannot be done through macros, like the drop down list.

HLA I think is kind of on the right track. I think some of this can be done with macros.

My opinion is why would I want to waste the time to learn how macros/fasm works when I could put that same time into developing my own assembler and debugger. The two would take about the same period of time, yet in the end my product would be superior for my goals, since fasm would still in the end only be an assembler. I would have wasted a lot of time coding macros instead of coding code.

My personal preference for coding OS's would be I think SolarOS over MenuetOS. I think the priorities are right. MenuetOS has seemed to go for the fun stuff rather than the stuff that needs to be done. In my opinion before MenuetOS goes any further, this is what it would need:
1.) Memory management
2.) OS supplied GUI objects(such as scroll bars, etc)
3.) Support for calling functions(libraries will be needed). Programming also is so much easier if you can do something like call createwindow rather than int 0x40 with registers set. This also slows down the processor more than a call would.
I don't know SolarOS too well, but it looks like it seems to be covering more of the basics first. It still isn't using the calls though(to my knowledge it still uses interrupts).

My thoughts for an OS is as follows:
1.) GUI stuff is given to the OS once and that is it. No need for program to redraw windows since the OS would have already stored this info.
2.) Segment register set to 0, all memory/code access is done within the 4GB. This facilitates the need for relocateable code(tables like the EXE's do), which is done at the beginning. This will save a huge amount of time with task switch though, since anything with protected mode segment registers takes quite a few cycles.
3.) Support for existing real mode code. Allow dos programs to run. This allows us to use drivers until, the native drivers are made. A good example of this is my Matrox Millenium card. It only supports 800x600 in vesa modes. However I got a little TSR that allows vesa to support all the video modes of the card. My OS will be able to run before DOS or after DOS has loaded.
4.) Co-operative multitasking. Avoids unnecessary task switches.

You can see why I like SolarOS. I would gladly support the efforts of SolarOS, but up to recently the development seemed kind of stagnant and there was no place to post the code.

I find it interesting how several people on this forum do support coders. Whenever an idea is mentioned, they seem to not even hear the specs of what the person is saying. Like in my example nothing exists that does what I want, so if I am going to do something new I want to make it as good as possible. However, there are several responses that say "You shouldn't code anything else, if you do code anything you should code for menuetos".

An OS should stand on its merits. It shouldn't need to have people say you should be programming in this OS rather than elsewhere. Make the OS programmer friendly and people will naturally support it. MenuetOS is not programmer friendly. The three biggest issues are call functions not supported, no debugger, and no OS supplied GUI objects. The way it handles the GUI is the biggest reason though, since this is core to the OS and can't really be changed.

I don't mind intellectual discussions, but obviously I am not getting a whole lot of ideas here which is what is expected in a way. Tom's idea about the Wirth stuff was interesting, I guess I can look into some Delphi manuals to see what their coding format is like.

Let me save some people some time then, here would be two common responses:

I should be using fasm with macros for everthing.
I shouldn't waste time programming other projects, but should be writing programs for MenuetOS.

If those are your responses, thank-you, I can appreciate where you are coming from, but it ain't going to happen. Thanks for the input anyways though.


...Gomer73

Some notes:

1)SOLAR OS uses:
- "Call API_Create_Window STDCALL, parameters.." for ALL of it functions.
-INTS are NOT used for application programming, only IRQs are used for drivers
-Solar OS does have a set of easyly extensible OS supplied GUI objects in the most natural OOP style (parents,events etc): window,buttons,edit,checkbox,MDI windows

2)It is my intention to provide a greater set of GUI objects in the next release
-Scroll bars
-ListBox
-Combo Box
-Improved Simple Edit (caret)
-Big Edit (righ edit style)
-A console mode with write and forget style
-A debug API (at least OutputDebug String/Value) to a system debugg viewer
-Icons/bitmaps

However those could be easyly implemented by users because of the OOP/event driven architecture. I the next version i will show an custom control template that could be used by programmers

3)SOLAR OS does have dynamic Memory allocation routines, but i thought that Menuet has them also

4)Cooperative multitasking and full shared memory model make programming more easy and faster, basicaly SOLAR OS is much faster and more stable
"interprocess comunications" and "shared memory" are "natural"

5)Developement of SOLAR OS is faster now
since i have lost my daytime job and got a much more interest into my OS lately.

I somehow think that MenuetOS should "steal" my GUI concepts and adapt them to its needs (aka multithreading). I did proposed this to Ville a long time ago, the offer is of course still valid... but this requires some heavy changes into Menuet...

I also personally dislike INT 0x40 with parameters into registers and it hink that slows developement, but do not forget that Linux uses that

But please not that there are some current problems with SOLAR OS also !
Most notable (but not for long):
-----------------------------------------

1)Applications must be compiled embeded inside OS
Or else relocations might be needed.
All global variable are shared so private global variables require either usage of window_data01 space or dynamic memory alocation

2)Practically you should use TASM and that is commercial, MASM is the best seccond choice, FASM + macros the 2/3rd, NASM the 4th

3)There is no global system API table (i simply forgot about this...damn i am stupid) so you might have to recompile applications for every new version of OS (no problem IF sources are send to me)

4)There are not so many drivers (no network yet) and applications available for SOLAR

5)I do redraw the screen much too offten ;P
And until the console mode application is released you still have to draw on ACT_PAINT
However controls draw themselfes and do basic operations (move/resize/minimize/etc) without you programming
There is an experimental Video_Dirty function for optimizations

Sweet, I knew there was a reason I liked SolarOS.
Looks like you're right about the MenuetOS memory thing. Looks like I was looking at an old post.

¿Could I ask you why?
(please don't missunderstand me, not criticism here, only plain curiosity)

Well because i have a licence for TASM
and i also like TASM's features like:
- Call's with parameters without macros
- local variables, IF/ELESIF/ENDIF etc
- STRUCTURES and UNIONS definitions
- incredible high build speed

basically i simply like TASM

So i am writting my own free assembler compatible with TASM's syntax to avoid this dependency in the future