Scripting language of choice?
Pages: 12
Well it depends on your needs. I've actually found articles on line where some programmers have used assembly as a scripting language just to see if it was possible.
Speaking of assembly languages, I'm designing a stack-oriented, pseudo-object-oriented* assembly language. It looks like this:
Every program consists of one or more pseudo-classes** like the one above, each with an optional 'init' and 'exit' function, with exactly one 'main' function per program. The 8 byte offsets of all the 'init' and 'exit' functions are in the executable header followed by the address of the main function. The processor loads and runs all of the init functions (the order is probably the same as the order in which they appear in the file(s), but that can't be relied upon) and then runs the main function. When that's done, it runs all the exit functions (again, the order can't be relied upon). All you can be sure of is that all the init functions will run before the main function which will be run in order (unless it's pipelined, but I have no idea how that works) followed by all the exit functions. init and exit functions can't call any external functions (because that might introduce circular dependencies). Code in the [readonly] and [readwrite] sections cannot be executed and code in the [readonly] and [execute] sections cannot be written to. The assembler will re-organise the program so that all the sections are together (code first, with read-only and read-write data at the very end), and mark each section with a flags byte. Three of the bits will be read/write/execute (like UNIX file permissions) and the other 5 will be reserved for now.
I want to have built-in thread synchronisation primitives as well, such as a prefix for an "atomic" block (every single instruction will be atomic but there will be an "atomic" instruction to stop the processor changing threads until an "endatomic" instruction is encountered).
* in that it looks like object-oriented code, but it's not, because you can't create objects at runtime.
** in that they're more like nested namespaces than classes.
|
|
Every program consists of one or more pseudo-classes** like the one above, each with an optional 'init' and 'exit' function, with exactly one 'main' function per program. The 8 byte offsets of all the 'init' and 'exit' functions are in the executable header followed by the address of the main function. The processor loads and runs all of the init functions (the order is probably the same as the order in which they appear in the file(s), but that can't be relied upon) and then runs the main function. When that's done, it runs all the exit functions (again, the order can't be relied upon). All you can be sure of is that all the init functions will run before the main function which will be run in order (unless it's pipelined, but I have no idea how that works) followed by all the exit functions. init and exit functions can't call any external functions (because that might introduce circular dependencies). Code in the [readonly] and [readwrite] sections cannot be executed and code in the [readonly] and [execute] sections cannot be written to. The assembler will re-organise the program so that all the sections are together (code first, with read-only and read-write data at the very end), and mark each section with a flags byte. Three of the bits will be read/write/execute (like UNIX file permissions) and the other 5 will be reserved for now.
I want to have built-in thread synchronisation primitives as well, such as a prefix for an "atomic" block (every single instruction will be atomic but there will be an "atomic" instruction to stop the processor changing threads until an "endatomic" instruction is encountered).
* in that it looks like object-oriented code, but it's not, because you can't create objects at runtime.
** in that they're more like nested namespaces than classes.
Last edited on
Been thinking about getting back into Assembly for the heck of it. I installed my Emu8086 on Vista and Ubuntu, but only tutorials I know of are the few that come with the Emu8086 emulator. Using it as a scripting language is out of my league big time.
I like assembly. I just don't like using the random assembly language interpreters -- they are never quite the same as the real thing...
The only assembly I know is basics (not used it since my college course) if you can call them that with Emu8086:
I remember we learned to do more with it, but that is all I can remember off the top of my head. Just can't find any good tutorials that teach it again. I think Emu8086 has a tutorial series I need to look into that again.
|
|
I remember we learned to do more with it, but that is all I can remember off the top of my head. Just can't find any good tutorials that teach it again. I think Emu8086 has a tutorial series I need to look into that again.
@Duoas,
This is just a sort of academic exercise. I don't know how to parse more complex stuff but assembly languages are quite simple. Otherwise I'd be designing something more useful.
This is just a sort of academic exercise. I don't know how to parse more complex stuff but assembly languages are quite simple. Otherwise I'd be designing something more useful.
Topic archived. No new replies allowed.
Pages: 12