I've started to find improvements to my forth x86/IA-32 assembler, thing I noticed is that I'd need some interface independent from the assembly language to make it useful! There are all kinds of interfaces like gcc and such for this, but they are really too complicated.
I'm asking whether people around have ideas for such language, I've already watched SEAForth -chip's assembly language and learnt from it a bit about what I need to do this.
The problem is I'd like my assembler to be portable, simple by design and easy to use. It'd be plus if I could also implement processor-specific stuff with it. So, the abstraction should be quite advanced, still a bit leaky! I have future intentions in porting everything to other processor sooner or later; I do not trust that staying in x86 architecture will make any good for an OS.
What kind of features should middle-language have to ensure I get what I want by redesigning my assembler?
The assembler is public domain, so just ask if you want it. Thought, it is not usable to many things currently...
assemblers: portability, simplicity, usability?
assemblers: portability, simplicity, usability?
Last edited by Cheery on Mon Oct 23, 2006 10:25 am, edited 2 times in total.
Windows Vista rapes you, cuts you and pisses inside. Thought these are just nifty side-effects.
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
so what are you looking for, exactly? a unified language to represent machine code that you generate out of your FORTH sources? and then use it to feed a processor specific assembler to turn it into binary code ? is that right ?
iirc, that was more or less the intent of Gnu AS, which might have the largest choice of target platforms. You cannot completely abstract the differences, of course, but at least include directives, comments, padding, datastructures, labels, etc. would work the same regardless of the actual target platform.
iirc, that was more or less the intent of Gnu AS, which might have the largest choice of target platforms. You cannot completely abstract the differences, of course, but at least include directives, comments, padding, datastructures, labels, etc. would work the same regardless of the actual target platform.
Sorry for telling things inconveniently. What I meant is that I simply need ideas and some already existing knowledge to build a portable assembler with forth scent. Ie. I will do forth interpreted code which shits out binary sources to format I want, in forms I want. So that the resulting code is not forth but binary, and doesn't use stack but registers and immediate slots.
ie. Something like:
[ $200 org ]
: addstuff
2 3 + 1 + ;
[ $0 org ]
addstuff
done
[
would turn to stuff equivalent for:
org 0x200
addstuff:
mov $2, %eax
add $3 %eax
add $1 %eax
ret
org 0x0
call addstuff
halt
If I remember right the GNU AS -syntax.
This is overly simple example, which doesn't take most things to count. But should give you the idea what kind of ideas I am looking for.
ie. Something like:
[ $200 org ]
: addstuff
2 3 + 1 + ;
[ $0 org ]
addstuff
done
[
would turn to stuff equivalent for:
org 0x200
addstuff:
mov $2, %eax
add $3 %eax
add $1 %eax
ret
org 0x0
call addstuff
halt
If I remember right the GNU AS -syntax.
This is overly simple example, which doesn't take most things to count. But should give you the idea what kind of ideas I am looking for.
Windows Vista rapes you, cuts you and pisses inside. Thought these are just nifty side-effects.
I don't know if this is useful for you but I thought it might be worth mentioning. I'm currently working on a "compiler" for what I temporarily call a meta-language. This "language" separates the input into three parts: initial output, the modify block, and what follows the modify block. The first part simply becomes the start of the output. The second part contains a grammar definition in PEG form (see: http://en.wikipedia.org/wiki/Parsing_expression_grammar), which is used to modify the initial syntax-tree. Then it parses the third part using the modified syntax-tree, generating a parsed tree (similiar to an AST http://en.wikipedia.org/wiki/Abstract_syntax_tree, however it also incorporates some code (defined in the second block) in every node, to be executed bottom-up and in order).
Basicly my attempt is to allow a more flexible an faster way to prototype programming languages. However it also allows for example for one to write a parser for a specific language (for example Forth in your case) as some simple rules, that outputs to another language (for example some sort of SSA (http://en.wikipedia.org/wiki/Static_sin ... nment_form) intermediate language), and then another parser for that second language into another language (for example asm, or just pure binary).
I'm still coding it for fun and as a proof-of-concept. It is still unstable (such that it's current version is numbered 0.-1.2), and it's coded in ruby (because of some language facilities) resulting in a very poor compile time performance (and I mean very poor depending on the situation).
Anyway, it might aid you in someway. Feel free to contact me,
JVFF
PS: I have a post on gamedev forums outlining what I planned to do. The plan has changed in most parts (especially in the virtual machine department), but it does outline the goals in someway: http://www.gamedev.net/community/forums ... _id=411775
Basicly my attempt is to allow a more flexible an faster way to prototype programming languages. However it also allows for example for one to write a parser for a specific language (for example Forth in your case) as some simple rules, that outputs to another language (for example some sort of SSA (http://en.wikipedia.org/wiki/Static_sin ... nment_form) intermediate language), and then another parser for that second language into another language (for example asm, or just pure binary).
I'm still coding it for fun and as a proof-of-concept. It is still unstable (such that it's current version is numbered 0.-1.2), and it's coded in ruby (because of some language facilities) resulting in a very poor compile time performance (and I mean very poor depending on the situation).
Anyway, it might aid you in someway. Feel free to contact me,
JVFF
PS: I have a post on gamedev forums outlining what I planned to do. The plan has changed in most parts (especially in the virtual machine department), but it does outline the goals in someway: http://www.gamedev.net/community/forums ... _id=411775