Hi everyone. This is my first post here but not the first time I have been around this forum. I used to read the posts but never posted anything. I hope that I can learn a lot from you guys.
For the first post not to be boring, I thought maybe I could introduce my Open-source Assembly Library to those who are interested in the subject. The library is called OASML (Open-source Assembly Library) and targets 8086 CPU in real-mode. Instructions are 100% compatible with 8086 except for a few cases where shifts are compatible with 80186. One of the distinct features of the OASML 1.0 is that every single line of the code is commented. Procedures have a header as a comment which describes the details about them and include examples and notes. This library also supports simulated 32-bit instructions and the Input and output of 32-bit values.
You can read OASML 1.0's details here: here
Download OASML 1.0 from this location
I’ll be glad to hear your opinions and ideas and once again I’m happy to be a part of this community.
OASML 1.0 (Open-source Assembly Library)
-
kataklinger
- Member
- Posts: 381
- Joined: Fri Nov 04, 2005 12:00 am
- Location: Serbia
I just think it is out of date!Hi kataklinger,
First off, I appreciate that you replied to this post and second I wanted to say that if you had written codes for embedded systems, you would have never said something like that.
Aren't there still...?
1) Operating systems that use 16-bit instructions only?
2) Embedded systems that can't use modern CPU architectures?
3) Programmers interested in knowing the idea behind something?
4) Operating Systems running in protected Mode that allow the emulation of 8086 real-mode?
After all, I started this library months ago with the intention of contributing something to the open-source world and I guess I somehow have achieved what I was looking for. Your comment makes a lot of sense to me too because most of us are not interested in the 16-bit programming anymore but some people still like their console window.
First off, I appreciate that you replied to this post and second I wanted to say that if you had written codes for embedded systems, you would have never said something like that.
Aren't there still...?
1) Operating systems that use 16-bit instructions only?
2) Embedded systems that can't use modern CPU architectures?
3) Programmers interested in knowing the idea behind something?
4) Operating Systems running in protected Mode that allow the emulation of 8086 real-mode?
After all, I started this library months ago with the intention of contributing something to the open-source world and I guess I somehow have achieved what I was looking for. Your comment makes a lot of sense to me too because most of us are not interested in the 16-bit programming anymore but some people still like their console window.
-
kataklinger
- Member
- Posts: 381
- Joined: Fri Nov 04, 2005 12:00 am
- Location: Serbia
@ 1), 2):
Yes, there are 16bits CPU (microcontrollers) but 8086 is not in producion any more, and your library I guess is not portable to other architecture (Microchip PIC microcontroller for instance). I woud love to hear if you know any example of modren device with 8086. And yes, you are right I was thinking about desktop/server systems.
@ 3):
Isn't that the libraries hide what ideas are behind something?
@ 4):
OK, this makes sense
But I think that V86 mode is going to die after wide acceptance of EFI.
Yes, there are 16bits CPU (microcontrollers) but 8086 is not in producion any more, and your library I guess is not portable to other architecture (Microchip PIC microcontroller for instance). I woud love to hear if you know any example of modren device with 8086. And yes, you are right I was thinking about desktop/server systems.
@ 3):
Isn't that the libraries hide what ideas are behind something?
@ 4):
OK, this makes sense
But I think that V86 mode is going to die after wide acceptance of EFI.OASML 1.0 (Open-source Assembly Library)
I totally agree with you and the way that Libraries tend to hide the actual implementation from the user in order to make life easier for the programmer but except for when they are released to the public as an open-source library which involves the programmer in the code of the library too and lets him/her understand what is really going on.
If the creation of the OASML 1.0 library has taken 5 months, I have literally spent 2 months out of total to write comments and documentations for it so I guess it's not hiding anything from the programmer.
Just out of curiosity; have you even looked at the library?
If the creation of the OASML 1.0 library has taken 5 months, I have literally spent 2 months out of total to write comments and documentations for it so I guess it's not hiding anything from the programmer.
Just out of curiosity; have you even looked at the library?
-
Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Although there are 16-bit systems in existance (even 8-bit ones still), the 8086 is a relic from the past. Although some people like to program real mode oses, i must agree with the point that nobody making a modern os will consider using this library. Also i think its a bit awkward to say its written for the 8086 while you are using 80186 stuff, which effectively makes it NOT 8086 compatible.
Now for the actual contents:
The comments look kindof computer generated to me - they barely provide semantic content above the assembly language.
As for the speed optimisation you mentioned on your site: i'm missing the 'standard' optimizing tricks like passing all arguments in registers, omitting framepointer references, not to mention the more advanced trickery. Also there's no notion as of which processor you are optimizing for.
That said, its very complete and for the people targeted it is probably very useful indeed.
Now for the actual contents:
The comments look kindof computer generated to me - they barely provide semantic content above the assembly language.
As for the speed optimisation you mentioned on your site: i'm missing the 'standard' optimizing tricks like passing all arguments in registers, omitting framepointer references, not to mention the more advanced trickery. Also there's no notion as of which processor you are optimizing for.
That said, its very complete and for the people targeted it is probably very useful indeed.
-
kataklinger
- Member
- Posts: 381
- Joined: Fri Nov 04, 2005 12:00 am
- Location: Serbia
I read description at website. And I just have looked at code:
- conver.asm - looks great
- dos.asm - i think you late 10-15 years
- dword.asm - you late even more
- files.asm - as for dos.asm
- flags.asm - many of the methods you can change with a single inst.
- io.asm - at first i tought it has something eith I/O ports,
but it's printing to screen, and geting input from kbd (useful for dos)
- isrivt.asm - useful for DOS I guess
- kbd.asm - can help
- macros.asm - I saw some very useful things StrLabel, EPUSH, EPOP...
- math.asm - I hope there's going to be more things there
in next (32bits;)) version
- memory.asm - ok
- misc.asm - useful (sorting)
- string.asm - very useful
It is very well documented, and you can extract description of methods and make HTML documentation. Hope the next version will use all 32bits (or even 64) of modern CPUs
- conver.asm - looks great
- dos.asm - i think you late 10-15 years
- dword.asm - you late even more
- files.asm - as for dos.asm
- flags.asm - many of the methods you can change with a single inst.
- io.asm - at first i tought it has something eith I/O ports,
but it's printing to screen, and geting input from kbd (useful for dos)
- isrivt.asm - useful for DOS I guess
- kbd.asm - can help
- macros.asm - I saw some very useful things StrLabel, EPUSH, EPOP...
- math.asm - I hope there's going to be more things there
in next (32bits;)) version
- memory.asm - ok
- misc.asm - useful (sorting)
- string.asm - very useful
It is very well documented, and you can extract description of methods and make HTML documentation. Hope the next version will use all 32bits (or even 64) of modern CPUs
I think you have done a great job, well coded and commented, i also think its got alot of uses, eg: the more wide spread something is the more code is available, so dev have lots to chose from, the problem come's when you need something that is not so wide spread eg: a realmode job, theres no new code, that when you need stuff like this.
As a side note here a example make a program for XP and it will get lost in the number of other xp programs, but make it for DOS and it will get used, look here there still lots of users:
http://www.computing.net/dos/wwwboard/wwwboard.html
As a side note here a example make a program for XP and it will get lost in the number of other xp programs, but make it for DOS and it will get used, look here there still lots of users:
http://www.computing.net/dos/wwwboard/wwwboard.html
OASML 1.0 (Open-source Assembly Library)
First I wanted to thank you guys for considering looking at the library and then..
Combuster,
Well about the comments, I really have written all those and if they are really short, it's because I did not want the text to look mangled and cramped up in some text editors so I had to keep them short.
About the optimization, well there really is no such thing as optimization in 8086 compared to what we have now. Pairing, branch predictional and etc. What I mean by optimization in the OASML is using instructions that generally take less clock cycles to execute than others.
Passing all the arguments to procedures and function in general purpose registers was not what I had in mind while starting to create the library in the first place. I wanted the user to be able to keep the values in those registers except for the accumulator which is used for one-parameter procedures and for return values but I do agree with the improvement of speed that can be achieved using general purpose registers to pass parameters.
Kataklinger,
I appreciate that you took a look at the code and wanted to say that I've started coding the 32-bit version of the library but before that, I'm going to have to release OASML 2.0 because at the time of relasing OASML 1.0, I had already done half the coding of OASML 2.0 which supports 64-bit values in input/output and etc. I'm trying to code the 32-bit version too. Thanks to you for the motivation.
Dex,
I just can say thanks for the compliment and that I liked the web-site you posted a link to, a lot.
Combuster,
Well about the comments, I really have written all those and if they are really short, it's because I did not want the text to look mangled and cramped up in some text editors so I had to keep them short.
About the optimization, well there really is no such thing as optimization in 8086 compared to what we have now. Pairing, branch predictional and etc. What I mean by optimization in the OASML is using instructions that generally take less clock cycles to execute than others.
Passing all the arguments to procedures and function in general purpose registers was not what I had in mind while starting to create the library in the first place. I wanted the user to be able to keep the values in those registers except for the accumulator which is used for one-parameter procedures and for return values but I do agree with the improvement of speed that can be achieved using general purpose registers to pass parameters.
Kataklinger,
I appreciate that you took a look at the code and wanted to say that I've started coding the 32-bit version of the library but before that, I'm going to have to release OASML 2.0 because at the time of relasing OASML 1.0, I had already done half the coding of OASML 2.0 which supports 64-bit values in input/output and etc. I'm trying to code the 32-bit version too. Thanks to you for the motivation.
Dex,
I just can say thanks for the compliment and that I liked the web-site you posted a link to, a lot.