Index
> Non-x86 architectures > HJA430 --- is there RTL for the MSP430 anywhere? |
| Author |
|
|
Hugh-Aguilar 04 Apr 2021, 03:58
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?
_________________ When all else fails, write the source. |
|||||||||||
04 Apr 2021, 03:58 |
|
|
revolution 25 Apr 2021, 08:12
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. |
|||
|
25 Apr 2021, 08:12 |
|
|
Hugh-Aguilar 25 Apr 2021, 17:59
revolution wrote: We all have different interests and use cases. I don't want others to follow me --- that is why I don't provide source-code. _________________ When all else fails, write the source. |
|||
|
25 Apr 2021, 17:59 |
|
|
Hugh-Aguilar 02 May 2021, 20:16
Hugh-Aguilar wrote:
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. |
|||
|
02 May 2021, 20:16 |
|
|
Hugh-Aguilar 02 May 2021, 22:10
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. ... 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. |
|||
|
02 May 2021, 22:10 |
|
|
Hugh-Aguilar 07 Aug 2021, 03:06
Hugh-Aguilar wrote: ...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). I will post here the description of my TOYF processor that is loosely based on the MiniForth processor (they are both VLIW and oriented toward Forth). Once again, I won't post source-code --- I'm done with giving away source-code --- I don't want 'followers' who say: "When all else fails, steal the source." I'm interested in writing assemblers. My MFX for the MiniForth, and my assembler for the TOYF, are both examples of assemblers that can't be done with FASM/G (but for a different reason than why HJA430 can't be done with FASM/G).
_________________ When all else fails, write the source. |
|||||||||||
|
07 Aug 2021, 03:06 |
|
|
Hugh-Aguilar 15 Jan 2022, 02:44
Hugh-Aguilar wrote:
Well, I'm quite amazed that my MSP430 assembler documentation has been downloaded 205 times and this TOYF documentation has been downloaded 125 times. Most likely this is Red China trying to find something that they can use --- the commies are always lurking on forums such as this --- they rely heavily on stealing our technology because the communist social-system does not reward innovation. I'm reading the book: "To Engineer is Human" (Henry Petroski). He discusses the collapse of the Kansas City Hyatt Regency walkways in 1981, in which 114 people were killed and almost 200 injured. He says: Quote: But explaining what went wrong with the Hyatt Regency walkways and pointing out changes that would have worked, is a lot easier than catching a mistake in a design yet to be realized. After the fact there is a well-defined "puzzle" to solve to show how clever one is. Before the fact one must ... define the design "puzzle" ... This was the case with the MFX assembler. I was never told that the "puzzle" was to out-of-order the instructions. I was told to write the assembler such that the programmer put all of the instructions on each row that would execute in parallel, such that each row of source-code represented one opcode, and the rows just executed sequentially from top to bottom as in any assembler. This would have put the burden of out-of-ordering the instructions entirely on the programmers' unmuscled shoulders, which would have resulted in there not being any programmers (me neither, as I'm not smart enough to do that in my head any more than anybody else is). The project would have failed because few or none of the primitives would have gotten written. Bummer! I would not have taken the blame though, because I just did what I was directed to do --- what I actually did was not what I was directed to do, but instead I defined the puzzle and solved it --- the assembly-language programmer could write his source-code as if the instructions executed sequentially; the business of out-of-ordering the instructions and packing multiple instructions into each opcode would be done under the hood, with the assembly-language programmer not needing to know how this was done, or even know that this was done. This worked well. The MiniForth (built in a Lattice isp1048 PLD) was used in the motion-control board for a laser-etching machine --- the board (the Lattice PLD plus an 8032 helper) cost less and out-performed the competitor's board that used an MC68000 programmed in C (this was in 1994 before the ARM Cortex became dominant, at a time when it was still possible to be innovative and compete successfully with the mainstream processors). My algorithm that I invented for out-of-ordering the instructions is described in the TOYF document. It is not a complicated algorithm. Any reasonably smart programmer can understand this algorithm with a little bit of thought. Any reasonably competent programmer can implement this algorithm (you need to know how to implement a linked list, but that is easy, and that has already been provided in myriad code-libraries). After the fact, it is easy to say: "Anybody could have invented this algorithm and implemented it --- this is kindergarten-level programming." This is why inventing is a bad idea at a job, unless you are the boss --- you will never get praised! If you succeed, many maintenance programmers will take credit. At best you will be described as an early pioneer, but even that much credit is unlikely. Most likely, you will get fired because you are standing in the way of progress. If you fail, of course, you alone will take the blame! You are definitely getting fired in this case. Our capitalist social-system doesn't reward innovation either. P.S. I interviewed at Lockheed Martin to work on their VLIW processor that was used for turning radar-data into images. They don't have an assembler to do the out-of-ordering automatically. They were programming in a spreadsheet with each row representing one opcode and each cell containing an instruction all of which would execute in parallel. I didn't get the job. They seemed to not understand what I was telling them, that this out-of-ordering could be done automatically by the assembler. It is also possible that they did understand this but, like modern-day Luddites, they wanted to continue to get paid by the hour to do this manually. I have never heard of anybody else building a VLIW processor. P.P.S. I knew about out-of-ordering because I had read Abrash's book about the Pentium processor with its U and V pipes, and how it did out-of-ordering at run-time. The MiniForth was more complicated because it had five instructions per opcode executing in parallel, rather than the Pentium's two instructions (U and V). The MiniForth was easier though, because I did the out-of-ordering at compile-time with a Forth program, rather than at run-time with hardware. _________________ When all else fails, write the source. |
|||
|
15 Jan 2022, 02:44 |
|
|
Hugh-Aguilar 11 Apr 2023, 00:16
Hugh-Aguilar wrote: Well, I wrote an assembler for the MSP430. Well, HJA430 no longer works under VFX. Stephen Pelc, the owner of MPE that sells VFX, sabotaged VFX so that it would no longer compile certain parts of my novice-package, despite the fact that my novice-package is ANS-Forth compliant (except for the rquotations that I wrote in x86 assembly-language and that only work under VFX and SwiftForth). This sabotage is discussed here: https://groups.google.com/g/comp.lang.forth/c/hp1MbSkew08 Code: On Thursday, February 23, 2023 at 5:53:49 AM UTC-7, Stephen Pelc wrote: > On 19 Jan 2023 at 04:34:11 CET, "Hugh Aguilar" <hughag...@gmail.com> > wrote: > > > The bug is that this ANS-Forth compliant code causes VFX to crash: > > ------------------------------------------ > > : lit, ( val -- ) \ runtime: -- val > > postpone literal ; > > ------------------------------------------ > > For the moment define LIT, as > > : lit, ( val -- ) \ runtime: -- val > postpone literal ; doNotSin > > An upcoming version of VFX may/will use a different fix and will not require > DONOTSIN. > > Stephen > > -- > Stephen Pelc, ste...@vfxforth.com > MicroProcessor Engineering, Ltd. - More Real, Less Time > 133 Hill Lane, Southampton SO15 5AF, England > tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612, > +34 649 662 974 > http://www.mpeforth.com - free VFX Forth downloads There are actual multiple cases in which VFX has been sabotaged to not compile ANS-Forth code, although the DoNotSin patch undoes the sabotage, but Stephen Pelc isn't telling where DoNotSin is needed. I had to switch to using SwiftForth, although SwiftForth is abysmally slow compared to VFX --- the speed of the HJA430 assembler isn't very important though, even with large source-code files to assemble. If I got rid of my rquotation use, HJA430 would be ANS-Forth, except for the fact that I use the $ prefix for hexadecimal numbers which is not ANS-Forth VFX and SwiftForth both allow this, and some other ANS-Forth compilers might also allow this. The $ prefix has been common practice since the 1980s, or maybe even the 1970s, and I'm accustomed to it. Stephen Pelc doesn't say why he sabotaged his own compiler. Most likely he considered HJA430 to be a "sin" because it is an alternative the MPE's commercial MSP430 development software ($$$). I'm not actually distributing HJA430 publicly though. It is only for my own use, as well as a few close associates --- so I wasn't using VFX to compete against MPE anyway! WTF?  I'm bummed out to learn that Stephen Pelc considers me to be a sinner. Should I go to confession and tell the priest that I wrote an MSP430 assembler? In the 16th century I would have been burned at the stake for writing an MSP430 assembler!
BTW: I notice that we are to almost 500 downloads. WTF? There is no purpose in downloading documentation when the source-code is not provided --- this is like software-pornography --- you get to read about the software, but you don't get to use the software. I think that we can assume that Tomasz Grysztar is smart enough to not sabotage FASM, but will continue to ensure that FASM assembles correctly so that legacy FASM source-code will continue to work correctly without any DoNotSin patch needed. Also, Tomasz Grysztar is important enough of a person to not self-destruct just because somebody such as myself is writing an assembler that is in competition to an assembler that Tomasz Grysztar has written or will write. I would actually like to see Tomasz Grysztar or some of his followers write an MSP430 assembler so that I could study it and possibly learn something. If I'm a sinner for writing an MSP430 assembler, you might as well join me in doing this. I doubt that you are going to get control-flow structures comparable to my {...} structures, but still, you might have features that I don't have and that I could learn about. When I started this thread, I had assumed that there was an MSP430 assembler written in FASM, although I now realize that only the 8051 and AVR8 have been supported, and only partially. Question for Tomasz Grysztar: Do you have any intention of supporting the MSP430? I would be interested in seeing how you go about doing what I have already done. Presumably, yours would be a lot different from mine! Another question for Tomasz Grysztar: Do you have any intention of supporting the STM8? I have already started porting HJA430 over to generate code for the STM8, but I'm not finished. The STM8 gets as much or more use as the MSP430, although the 8051 and AVR8 are mostly obsolete. _________________ When all else fails, write the source. |
|||
|
11 Apr 2023, 00:16 |
|
|
revolution 11 Apr 2023, 03:19
Hugh-Aguilar wrote: BTW: I notice that we are to almost 500 downloads. WTF? There is no purpose in downloading documentation when the source-code is not provided --- this is like software-pornography --- you get to read about the software, but you don't get to use the software. I like to read informative documents regardless of whether I have the software or hardware. It can provide insights, or ideas. Give inspiration. And generally make one more informed and aware of what is available and possible. Maybe it is all these newfangled LLMs that are downloading it and infusing it into their NNs.  |
|||
|
11 Apr 2023, 03:19 |
|
|
Tomasz Grysztar 11 Apr 2023, 09:17
Hugh-Aguilar wrote: Question for Tomasz Grysztar: Do you have any intention of supporting the MSP430? I would be interested in seeing how you go about doing what I have already done. Presumably, yours would be a lot different from mine! |
|||
|
11 Apr 2023, 09:17 |
|
|
Hugh-Aguilar 12 Apr 2023, 05:11
Tomasz Grysztar wrote:
I understand the idea of FASMG, that the "assembler construction kit" can be used to retarget your assembler for different processors easily. This would be useful to anybody working with a lot of different processors. The problem for people working with a lot of different processors is not the lack of an assembler (writing an assembler is easy enough; I've done it more than once). The problem is that they have to rewrite their application program when moving from one processor to another. The C language supposedly allows source-code to be recompiled without change for different processors --- C is a truly ugly language though --- it is also too high-level for microcontrollers, due to its origin as a language for implementing Unix on mini-computers in the 1970s. I did have an idea that you might be interested in. 
I'm currently working on developing an FPGA processor. This processor has support for running a byte-code VM (called PVM) in external memory. My idea is that the PVM assembler could be retargeted to generate machine-code (not byte-code) for various processors. You could have a PVM430 assembler that takes PVM source-code and generates MSP430 machine-code. Some of those byte-codes will have to be assembled as subroutine calls because they are quite high-level, but a lot of the byte-codes can be assembled as macros that generate only a few MSP430 instructions. You could also have a PVM24 assembler that takes the same PVM source-code and generates PIC24 machine-code. You could have a lot of PVMxxx assemblers, each targeting a different processor, but all assembling the same source-code to produce a program that does the same thing. The purpose of all these PVMxxx assemblers is not to use each processor to its full potential. Most or all of the processors are going to be used at only a fraction of their full potential. The purpose of this exercise is to allow programs to be easily ported between processors. Also, if a compiler (Forth or C or whatever) is written for the hypothetical PVM processor, it can be used to generate code for a variety of processors. If a new processor needs to be supported, a new PVMxxx assembler needs to be written to generate code for that processor, but the compiler that generates PVM code does not need to be rewritten. This is good because compilers are big and complicated so retargeting them is a lot of work. PVM is essentially an intermediate code-format between the compiler and the processor. Code: PVM has these 16-bit registers: TOS --- top item of data-stack SP --- data-stack pointer IP --- instruction pointer RP --- return-stack pointer UP --- user base pointer PVM has these 32-bit registers: PD --- 32-bit accumulator MD --- 32-bit working register Because we are generating machine-code, not byte-code, the IP register would be the PC register. Any processor that gets a PVMxxx assembler should be powerful enough to efficiently run PVM code. Your target processor should have enough registers that most or all of the PVM registers can be mapped to actual registers rather than pseudo-registers in memory. You could have a PVM02 assembler that generates 65c02 machine-code, but it would be very inefficient; pretty much every PVM instruction would be a JSR to a subroutine because generating 65c02 code with macros would be too bloaty. Some processors, such as the PIC24, are a lot more powerful than the hypothetical PVM so most of the PVM instructions can be macros that generate PIC24 machine-code, but the program is going to have a fraction of the efficiency of a PIC24 assembly-language program (it is only using about half of the PIC24's registers). On a processor such as the PIC24 that has a lot of registers, it would be a good idea for the main-program and the ISRs to have different registers mapped to the the PVM registers so you don't have to save/restore a lot of registers entering and exiting the ISRs. Thoughts? _________________ When all else fails, write the source. |
|||
|
12 Apr 2023, 05:11 |
|
|
Tomasz Grysztar 12 Apr 2023, 06:02
What you seem to describe is an advanced kind of an assembler, providing an abstraction layer over several architectures. Yes, you could do that with fasmg, too. You could even take some already existing instruction sets for fasmg and implement a completely new syntax as an abstraction over them. It's all easy, but obviously requires doing some work, designing the syntax and writing the macros implementing said syntax. But fasmg is capable of providing a robust toolkit for any such project.
|
|||
|
12 Apr 2023, 06:02 |
|
|
Hugh-Aguilar 13 Apr 2023, 03:57
Tomasz Grysztar wrote: What you seem to describe is an advanced kind of an assembler, providing an abstraction layer over several architectures. Yes, you could do that with fasmg, too. You could even take some already existing instruction sets for fasmg and implement a completely new syntax as an abstraction over them. It's all easy, but obviously requires doing some work, designing the syntax and writing the macros implementing said syntax. But fasmg is capable of providing a robust toolkit for any such project. Yes, all big dreams require doing some work --- usually a lot of work. 
I don't need any help with my project right now. I can write my own assembler without difficulty, and I can write the Forth system on top of that without difficulty. Eventually however, I may need a C compiler because a lot of people (Americans) will refuse to consider the processor until there is a C compiler available. The reason why I chose to support a byte-code VM in external memory is to give myself flexibility for the future. A byte-code VM can be changed in software by rewriting all or most of the primitives in internal-memory. The Verilog doesn't need to be rewritten to switch from Forth to C or any other language. The native assembly-language used internally is pretty low-level, but any competent programmer should be able to master it --- all that is needed is to write byte-code primitives, which should be easy enough. FASMG would mostly be needed for an assembly-language for a byte-code VM that is designed for C rather than Forth. It would be great if this byte-code VM could also do double-duty as: "an abstraction layer over several architectures" (your accurate term). This way the C compiler would not just generate code for my byte-code VM, but could also be used without modification as the front-end for a variety of processors. This would presumably provide better speed because these versions of the assembler would be generating machine-code rather than byte-code in a VM (maybe not though; it depends upon how closely the target processor ISA matches the virtual ISA). Essentially, FASMG for this hypothetical processor would provide respectability to my project that I won't have with Forth. This is a consideration for the distant future. Right now, I'm just going ahead with Forth both for the machine-code that runs internally and the byte-code VM that runs in external memory. Do you know C? Has FASM or FASMG ever been used as the back-end of a C compiler? I have only used other people's C compilers, but have never written a C compiler of my own, so I have only a superficial familiarity with C. Writing a C compiler is not something that I'm interested in doing, so I would put that off to the distant future or find somebody else to do it (hopefully somebody who cares about C). P.S. I originally wanted to use the W65c816 as my byte-code VM. I was highly enthusiastic about this because the '816 has one-byte opcodes, not multi-byte opcodes as in the MC6811 or MC6809, so it would be easy to emulate. I was hugely disappointed to find that there is no C compiler available for the W65c816. The WDC website (https://www.westerndesigncenter.com/wdc/tools.php) says: Quote: WDCTools are provided for use in development of products that feature 65xx processors from WDC and its licensees. They are NOT for reverse engineering of our technology in any form and is NOT provided for development of commercial products that use non-WDC 65xx processors in Core or Chip form. So, that killed the W65c816 as my "abstraction layer over several architectures." _________________ When all else fails, write the source. |
|||
|
13 Apr 2023, 03:57 |
|
|
Hugh-Aguilar 16 Apr 2023, 03:09
Hugh-Aguilar wrote:
Well, I found that there are some third-party C compilers for the W65c816. I will look into these to determine if they could be used to allow me to have C without requiring me to write a C compiler. One of them is based on LCC, which I looked into previously in regard to the MiniForth processor. I have already begun work on PVM though, so I will just continue with that for now. The byte-code VM is in software, so it is possible to support more than one byte-code VM. I could have both the W65c816 (for C programmers) and PVM (for Forth programmers). Assembly-language programmers such as yourselves will likely find W65c816 assembly-language easier to learn than PVM (because PVM is primarily intended to be the back-end of a Forth compiler) --- so, if FASMG does ever get used on my processor, it would most likely be for the W65c816. If I do use the W65c816 as an "abstraction layer over several architectures," I will modify it slightly. For one thing, I would definitely get rid of 8-bit mode. That is really an artifact of the Apple-IIc (just as useless as the human appendix). Getting rid of the instructions related to 8-bit mode makes these opcodes available for new uses, such as a multiplication instruction. I would also require 16-bit data to be even-aligned because my data-bus is 16-bits. I would also map the lower 1K to internal memory, so we could have four direct-pages that are fast. None of these changes should prevent an existing C compiler from working. There might be a slight modification needed to make data even-aligned, and to make sure that the direct-page is always (or, at least, usually) in the lower 1K. Ultimately, I would like to see the more advanced users write custom byte-code VMs for my processor. These could be for languages such as BASIC, Pascal, Promal, etc.. I would focus on Forth because that is what I know. For the processor to become popular though, it needs to support C and other mainstream languages. _________________ When all else fails, write the source. |
|||
|
16 Apr 2023, 03:09 |
|
|
Hugh-Aguilar 23 May 2023, 02:00
Hugh-Aguilar wrote: I don't need any help with my project right now. I can write my own assembler without difficulty, and I can write the Forth system on top of that without difficulty. Well, I wrote my assembler/simulator for my processor. 
The simulator uses my <SWITCH code in the novice-package. I attached a document describing <SWITCH since you folks seem to want to read documentation for software despite not getting the software. At this time, my simulator just displays the machine-code and the registers and the Forth data-stack, etc.. I have breakpoints and watchpoints. I'm mostly focusing on verifying that the assembler is generating correct code, so I'm okay with having only machine-code displayed. I can upgrade this later to do source-level debugging --- I had this in the past (1990) with my 65c02 Forth cross-compiler --- I don't really need this myself for writing the byte-code VM primitives, which is my next project, although it could be useful for a program written purely in assembly-language. What is used in FASM or FASM/G for debugging? Does FASM/G have support for the user to write a simulator, or does FASM/G only support the assembler? Hugh-Aguilar wrote: The reason why I chose to support a byte-code VM in external memory is to give myself flexibility for the future. A byte-code VM can be changed in software by rewriting all or most of the primitives in internal-memory. The Verilog doesn't need to be rewritten to switch from Forth to C or any other language. Another reason why I'm interested in a byte-code VM is that this allows the main program to be in external memory. Only the byte-code VM primitives need to be in internal code-memory, as well as ISRs. Internal data-memory holds the data-stack and a direct-page of data (similar to the direct-page of the 65c02). My processor only has 6KW of internal code-memory and 2KW of internal data-memory, which is not very much, so this would be used for speed-critical aspects of the program. Has anybody ever written a byte-code VM in FASM for any processor? I want to get people interested in writing a byte-code VM and a compiler (preferably C, but Pascal etc. are also fine) for my processor. BCPL is interesting because it already has CINTCODE which is a byte-code VM. Also, BCPL assumes word-addressing, and my processor is word-addressed. C mostly upgraded BCPL to use byte-addressing, which was mostly used for 8-bit character strings, but I don't need this because I would be using UTF-16 in order to support both Latin and Cyrillic. I don't want to write a byte-code VM for C or any other non-Forth language because then I would be competing against myself. I'm currently writing a byte-code VM that is oriented to Forth. If I write a byte-code VM that is oriented to C, and write a C compiler for it, there are two possible results (in order of likelihood): 1.) The Forth byte-code VM will be more efficient than the C byte-code VM. Everybody will say that this proves that I'm incompetent because C is supposed to be more efficient than Forth. 2.) The C byte-code VM will be more efficient than the Forth byte-code VM. Everybody will say that this proves that I'm incompetent because I shouldn't have wasted time with Forth. I would much prefer that somebody else write the C byte-code VM and the C compiler. (presumably the back-end will be a FASM/G assembler). This is almost certainly going to be less efficient than my Forth byte-code VM, but I don't care because I'm not to blame for that. Supporting C would give my processor a lot of respectability, especially in America where C is required for any processor. I am told that C is not totally entrenched in Russia, but Forth is acceptable there. What is the situation in Europe? Poland, for example? Is C required there? I am told that in Poland there is a man Filipiak who has a monopoly on government contracts for programming. Filipiak infamously said that one programming expert can be replaced with ten programming students. When any programming student rises to expert level, he does not get a raise in pay; he gets fired. The expectation in replacing him with multiple students is that at least one of those students will rise to expert level, so there will always be at least one expert working on any software package (until he gets fired and another expert rises to the top, only to get fired, etc.). This is essentially a Pyramid Scheme because it depends upon finding ten students to hire who haven't already been hired and fired (either because they were incompetent, or because they rose to expert level and asked for a raise). Filipiak has already run out of students in Poland and has now begun hiring from Ukraine. Now that there is war in Ukraine, that is probably not working out for him, so he likely has moved on to hiring students from some other country (India would be the obvious choice). Now we have the verb "filipiakize" to describe this process. Is my description of Poland accurate?
_________________ When all else fails, write the source. |
|||||||||||
|
23 May 2023, 02:00 |
|
|
macgub 24 May 2023, 11:48
I never heard about Mr Filipiak - but i am not commercial programmer. The money paradigm is for me less importand than 'good mood' and health...
But I understand others.. Everyone must eat bread to live... @Hugh-Aguilar - best wishes for you an your work !!! |
|||
|
24 May 2023, 11:48 |
|
|
Hugh-Aguilar 26 May 2023, 02:52
macgub wrote: I never heard about Mr Filipiak... I was told about Filipiak by a guy on an internet forum named Zbigniew. This is the Filipiak in question: https://en.wikipedia.org/wiki/Comarch [edited: I looked it up, and this is him: Janusz Filipiak of Comarch] Zbigniew is also a very common name in Poland, I'm told --- the person who told me about Filipiak was sending posts out of Poland, so I assume he is Polish. He was a decent enough fellow who generally made a positive contribution to the forums, so I assume that his story was true, about Filipiak's infamous quote regarding how any expert can be replaced by ten students. BTW: I have seen people on forums such as this who claim to have the name Zbigniew, but they never make a positive contribution. A Chinese friend told me that these people are not from Poland, but are actually Chinese. If you know how to trace forum posts, it can be determined that their posts are coming out of Red China, or sometimes being diverted through Russia to obscure their origin, but they aren't coming from Poland. Apparently, Beijing has huge teams of trolls whose job is to troll the internet forums striving to obtain source-code (this is a big part of why I don't post source-code on forums such as these). My Chinese friend says that a clue that they are actually Red China trolls is that the quality of their English varies from day to day --- this is because various people on the team will use the same login name in the forums from day to day, and they have various levels of education in English. Another clue is that they often claim to have the name Zbigniew and will pretend to be from Poland. The reason is that, in the Chinese language, "zbigniew" means: "I f**k you from day one." I asked another Chinese friend, the owner of a restaurant that I eat at, if this was true. He agreed that "zbigniew" in his language is an extremely vulgar insult, although he wouldn't translate it into English for me because you can't say things like that in a restaurant where the customers will hear you. This post was rather off-topic. I mostly mention this as an explanation for why I don't post source-code on forums such as this anymore. There are a lot of "programmers" in the world who can't program, but they only strive to steal source-code.  Many, but not all, are in Red China._________________ When all else fails, write the source. |
|||
|
26 May 2023, 02:52 |
|
|
macgub 28 May 2023, 04:58
Hugh-Aguilar wrote:
I think such situation is with many words.... For example 'tlen' word in Polish language means - 'oxygen', but in Kazakhstan means 'someone died' .... |
|||
|
28 May 2023, 04:58 |
|
|
Hugh-Aguilar 14 Jun 2023, 23:13
macgub wrote:
In Spanish, "introduzca" means "insert." I was working on point-of-sale terminals at the time, and the Spanish equivalent to "please insert your card" was: "por favor, introduzca su tarjeta." However, "introduzca" does not mean "introduce" in the sense of being introduced to a person. So, I was at this company party and there was this super-fine Venezuelan woman there. I asked my Spanish-speaking coworkers: "Por favor, introduzcame a la señorita." This resulted in much laughter! They said that they would be happy to acquaint ("conocer") me with her, but I would be on my own in regard to inserting myself into her. So, inadvertent comedy is possible in any language.
Those Red China trolls are doing it on purpose though. Their mentality is to insult people without the people realizing it. Also, they are in Beijing, so they won't get punched in the face if their insults are realized. _________________ When all else fails, write the source. |
|||
|
14 Jun 2023, 23:13 |
|
< Last Thread | Next Thread > |
Forum Rules:
|