flat assembler
Message board for the users of flat assembler.

Index > Non-x86 architectures > HJA430 --- is there RTL for the MSP430 anywhere?

Author
Thread Post new topic Reply to topic
Hugh-Aguilar



Joined: 26 May 2020
Posts: 40
Hugh-Aguilar
Well, I wrote an assembler for the MSP430.
I previously began work on Simple51 for the 8051 in FASM but gave up on that because FASM is too much work, and the 8051 is pretty much obsolete.
My MSP430 assembler called HJA430 is written in VFX. It was pretty straight-forward. I attached the documentation, if anybody is interested.

I have yet to test the code on an actual MSP430. I just looked at the code generated, and it seems to conform to what I expect.
Some aspects of the MSP430 are just a guess though.
For example, if the source is immediate (PC)+ and the destination is symbolic nnn(PC) I am assuming that the PC gets incremented by 2 after the effective address of the destination is calculated by adding PC to nnn. This is just a guess though.
As another example, I am assuming that the source operand (such as for symbolic or absolute addressing-mode) is prior to the destination operand (such as for symbolic or absolute addressing-mode). This seems logical because the source is prior to the destination in the source-code, but I'm just guessing.

All of these questions could be answered if I had RTL for the MSP430.
Is this available anywhere?
I assume that there is an MSP430 assembler written in FASM/G -- if so, how did you answer these questions?

Is there a simulator available for the MSP430?


Description: documentation
Download
Filename: HJA430.txt
Filesize: 30.1 KB
Downloaded: 30 Time(s)


_________________
When all else fails, write the source.
Post 04 Apr 2021, 03:58
View user's profile Send private message Reply with quote
Hugh-Aguilar



Joined: 26 May 2020
Posts: 40
Hugh-Aguilar
Hugh-Aguilar wrote:
Well, I wrote an assembler for the MSP430.

I'm amazed that my document has been downloaded 21 times. I didn't know there were that many people on this forum.

I have found a disassembler for the MSP430 so I now know that the machine-code operands are in the order of source then destination (the same order as in the source-code), and that the source effective-address is calculated completely, including the PC increment if it is (PC)+, prior to the destination effective-address being calculated. So, I have made a minor adjustment to my assembler to take this into account.
This seems inefficient to me. The MSP430 is not calculating the source and destination in parallel! Apparently the TI engineers opted to go with a very simplistic sequential operation and not do anything in parallel when there are two operands. This was the first assembler that I ever wrote for a processor that has instructions with two operands --- maybe a lack of parallelism is common in CISC processors.

I had originally posted this because I assumed that the FASM crowd knew MSP430, and that you could provide me with RTL for the MSP430. This thread was a waste of time because you don't have RTL for the MSP430, or know anything about the processor --- I glanced over the FASM/G directory and found that you have not written an MSP430 assembler.

_________________
When all else fails, write the source.
Post 25 Apr 2021, 02:57
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18027
Location: In your JS exploiting you and your system
revolution
We all have different interests and use cases.

So far you are the first to post anything about the MSP430. It might be that your post inspires someone else to take an interest. That would make you the pioneer for others to follow.
Post 25 Apr 2021, 08:12
View user's profile Send private message Visit poster's website Reply with quote
Hugh-Aguilar



Joined: 26 May 2020
Posts: 40
Hugh-Aguilar
revolution wrote:
We all have different interests and use cases.

So far you are the first to post anything about the MSP430. It might be that your post inspires someone else to take an interest. That would make you the pioneer for others to follow.

I don't want others to follow me --- that is why I don't provide source-code.

_________________
When all else fails, write the source.
Post 25 Apr 2021, 17:59
View user's profile Send private message Reply with quote
Hugh-Aguilar



Joined: 26 May 2020
Posts: 40
Hugh-Aguilar
Hugh-Aguilar wrote:
revolution wrote:
We all have different interests and use cases.

So far you are the first to post anything about the MSP430. It might be that your post inspires someone else to take an interest. That would make you the pioneer for others to follow.

I don't want others to follow me --- that is why I don't provide source-code.

The Safety Forth project is still in the works. When that is complete, I will be able to post code such as HJA430 closed-source. People would be able to use HJA430 for developing MSP430 programs, but they wouldn't be able to do a hostile-fork on HJA430 itself. So I would have users, but I would not have followers --- the problem with followers is that they aspire to be leaders, and pretty quickly with minimal work on their part --- by comparison, users don't normally cause much trouble, except for their tendency to ask dumb questions without first reading the manual.

HJA430 is written in VFX anyway, so it is not a FASM program.
I used my novice-package when writing HJA430, which made the project pretty easy. I rely heavily on linked lists for intermediate data storage. This requires a heap, because the linked list nodes get allocated in the heap and then, when the list is no longer needed, they get deallocated. I have rquotations that get defined in a parent function and the rq (execution token) gets passed into a HOF (higher-order function). The HOF iterates through the list and executes the RQ for every node. The rquotation has access to the parent function's local variables, despite the fact that the HOF has local variables of its own (the rquotation can't have any local variables of its own; it has to use the parent function's local variables).

FASM doesn't have a heap, or rquotations. Because of this, porting HJA430 to FASM would be complicated. This can be done though. A good trick for assembling forward references to an unsettled label, is to use the operand of the JMP as a link in a list. The unsettled label has a pointer that is NIL if there are no forward references yet, or is a pointer to the first JMP operand if there is a forward reference. This JMP's operand is NIL if there aren't any more forward references, or it is a pointer to the next JMP operand if there is a forward reference. This would be pretty complicated to do in HJA430 because there are multiple ways to reference an unsettled label.
* Conditional jumps can only use 10-bit relative.
* The unconditional JMP can use 10-bit relative, 16-bit relative or 16-bit absolute.
* The CALL can use 16-bit relative or 16-bit absolute.
With rquotations and a linked-list, all of this information about what kind of reference it is, can be stored in the list node. Using the old trick with linking the JMP operands worked well when all of the JMPs used the same addressing mode. It doesn't work so well when the forward references can be of multiple different addressing-modes because there is no place to store this information.
Also, the code-blocks have a list of lists. The first node is the first level, the second node is the second level, etc.. Each node is a list of forward references that have to be resolved when the code block finishes with }, and this code block is then removed from the list of lists so that what was the second node is now the first level.

So, I could port HJA430 to FASM, but the result would be a much bigger and more complicated program, due to not having a heap and rquotations, etc..
Another problem with porting HJA430 to FASM, is that it would no longer have a macro language. HJA430 written in Forth automatically uses Forth as the macro language. If HJA430 were written in FASM, then it would be necessary for me to write an interpreter for a mini-language that would then be used as the macro language --- if I'm going to write an interpreter though, then I might as well write a Forth system and just keep HJA430 in Forth.

So, lots of ideas are possible. I really chose a super-simple technique, of just writing HJA430 in Forth. Considering that this is a fun project and I'm not getting paid, why would I do anything other than the most simple technique?

I haven't yet looked at FASM/G. I doubt that it provides the resources needed for code blocks though. If it has a macro language, I doubt that it is capable of doing things such as adding a pre-decrement addressing-mode, which was trivial in HJA430. I'm not really into learning other people's software, such as FASM/G --- I mostly just program in Forth because I learned that way back in 1984, and it still works --- I almost never learn anything new.

I posted this on the assumption that the FASM crowd is interested in how assemblers work internally. Nobody has yet responded to this thread though, so it is possible that nobody is interested in the subject, or that everybody thinks that they already know more about the subject than I do.

_________________
When all else fails, write the source.
Post 02 May 2021, 20:16
View user's profile Send private message Reply with quote
Hugh-Aguilar



Joined: 26 May 2020
Posts: 40
Hugh-Aguilar
Hugh-Aguilar wrote:
A good trick for assembling forward references to an unsettled label, is to use the operand of the JMP as a link in a list. The unsettled label has a pointer that is NIL if there are no forward references yet, or is a pointer to the first JMP operand if there is a forward reference. This JMP's operand is NIL if there aren't any more forward references, or it is a pointer to the next JMP operand if there is a forward reference. ...
Using the old trick with linking the JMP operands worked well when all of the JMPs used the same addressing mode.

I recall using this trick in a 65c02 assembler. All of the forward jumps were 8-bit relative, so I just stuffed each operand with an 8-bit offset to the next operand. I didn't support forward JSR because that doesn't help with structured control-flow, which was the goal.

For the MiniForth assembler, none of this is relevant because the MiniForth did not have jumps or branches or calls --- it did not have any way to change the PC except with the NXT instruction --- all control-flow was at the Forth level, but there was no way to change control-flow inside of a primitive except to march forward until you eventually get to the NXT instruction that terminates the primitive. I think this aspect of the MiniForth weirds people out (I know it had that effect on me); there are no loops or conditional execution inside of a primitive, but each primitive just executes straight through until the NXT at the end (it was possible to conditionally load a register, similar to the CMOV instruction in x86).

_________________
When all else fails, write the source.
Post 02 May 2021, 22:10
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.