Index
> MenuetOS > What text editor does Menuet use? |
| Author |
|
|
Ville 13 Sep 2020, 11:47
I've written all Menuet applications in Menuets own text editor. Both displaying text and graphics to window is done with very similar system call.
Syscalls: www.menuetos.net/sys64.txt Example application: www.menuetos.net/e64.asm |
|||
13 Sep 2020, 11:47 |
|
|
Hugh-Aguilar 13 Sep 2020, 23:33
Will you be okay with Safety Forth being released closed-source?
Also, I don't want to pay for a certificate that proves that my closed-source code it is not malware. This is extortion. Will you be okay with Safety Forth programs written by users being released closed-source as binary-overlays? I can prove that any such program is not malware, because it can't access memory outside of its allocated space and it can't execute any machine-code except my built-in primitives. The technique for ensuring safety was figured out in Java --- I don't like Java though, because it is heavy on complexity and light on features --- I can use the same technique for safety, but in a better language. I am really done with open-source! For one thing, my code can get stolen and then sold at a profit. For another thing, I have had non-working versions of my code posted publicly as "proof" that I'm incompetent. These were either snippets of my code that had been modified so that they still looked like my code but no longer worked, or they were my prototype code from years previous that had bugs that I had since fixed. This is an example: On Friday, July 5, 2019 at 9:10:52 AM UTC-7, Howerd wrote: > I haven't had the time to debug your rquotations code - the test fails when run, with the error copied below. > This code is way too complicated for me - I prefer simple things like colorForth. I've turned the optimizer off, so it should work. > > Could you debug it for me (using SwiftForth), please? > > I uploaded what I have collated from your novice package and clf posts here : > www.inventio.co.uk/rquotations.f His "collated" code is just a mish-mash of code of mine that is not going to compile or run. His idea of debugging is to turn the optimizer off. He really doesn't know how the code works or what its purpose is. His only goal is to "prove" that I'm incompetent --- this is so he can continue to promote Forth Inc. (it is possible that he is a paid shill of Forth Inc. because all he does is promote SwiftForth, representing himself as an enthusiastic user). I really despise maintenance programmers! They are parasites. This is their typical attitude: On Monday, April 27, 2020 at 11:37:57 AM UTC-7, none albert wrote: > I have done my share of redesigning and documenting other peoples > programs and it is possible to slowly and surely improve. > Of course in order to be able to do that, one has to be > better than the original programmer, and determined. They always believe that they are better than the original programmer, a false belief that soon evolves into them saying that they are the original programmer. They do a lot of bragging about removing "cruft," which is their term for code that the original programmer wrote that they don't understand, or bug-ridden code that other maintenance programmers have introduced over the years (they can't tell the difference, so they just remove it all willy nilly) --- then they add some bug-ridden code of their own, which becomes cruft for the next maintenance programmer in the parade of fools. (my MFX that I wrote in 1994 is still in use at Testra, and there has been a long parade of maintenance programmers in that quarter of a century). For computer programming to survive as a way for people to have accomplishments, we have to get back to closed-source distribution. The open-source GPL idea that Richard Stallman promoted is just communism: * Everyone works toward the "common good" of their society. * Nobody has any accomplishments of his own, because every program was a team effort. * Everyone is expected to take pride in the accomplishments of their society. Linux is not the path to success because it is based on GCC that is not designed to be safe. Menuet as it currently stands is not the path to success either because FASM is not designed to be safe. Something like Safety Forth is needed. Of course, people can still write programs for Menuet in FASM, and they will get a lot better performance if they do, but they will likely have to be open-source in order for users to trust them to not be malware (this is assuming that the users have the time and expertise needed to examine the source-code to verify that it is not malware). _________________ When all else fails, write the source. |
|||
|
13 Sep 2020, 23:33 |
|
|
revolution 14 Sep 2020, 02:19
Hugh-Aguilar wrote: Also, I don't want to pay for a certificate that proves that my closed-source code it is not malware. |
|||
|
14 Sep 2020, 02:19 |
|
|
Ville 14 Sep 2020, 17:18
I'm fine with Safety Forth and applications being closed source. I can also put it up for a separate download at the Menuet www-page, if you want. However, the M64 disk image has been and will be an assembly only disk-image. This was our goal from the very beginning and it took us a long time to get here.
|
|||
|
14 Sep 2020, 17:18 |
|
|
Hugh-Aguilar 15 Sep 2020, 20:11
Ville wrote: I'm fine with Safety Forth and applications being closed source. I can also put it up for a separate download at the Menuet www-page, if you want. However, the M64 disk image has been and will be an assembly only disk-image. This was our goal from the very beginning and it took us a long time to get here. I'm okay with that. Most Menuet users are going to want to program in FASM, because that is the point of Menuet. Being an assembly-language purist gives a programmer a very elite status in the world --- might even be good for a free cup of coffee at Waffle House, so be sure to mention your elite status to the waitress. 
Safety Forth is primarily for people who want to distribute programs closed-source and/or who want to download programs and run them without worrying that those programs may be malware. Also, I have STRING-STACK.4TH and pseudo-reals etc., that make programming easier, especially for processing text files containing numeric data (such as the "big data" statistical calculations that we read so much about these days). It occurs to me that some Menuet programmers may want to implement Safety Pascal, or whatever. I don't think this will work very well. I originally intended STRING-STACK.4TH to be comparable to QBASIC strings (that is why functions such as MID$ are in there). I'm actually way beyond QBASIC now though, in pattern-matching and substring-extraction. QBASIC was always ahead of Pascal (QuickPascal and Turbo Pascal), so I really doubt that a Pascal implementation is going to have anything comparable to my STRING-STACK.4TH. Nevertheless, if anybody wants to write a Safety Pascal or whatever, I have included a code snippet from Safety Forth that shows my register usage. If anybody's Safety Pascal or whatever were implemented, it might be helpful to have the same register usage. This is so binary overlays could be used interchangeably. Some more information is needed to make this work, which I can provide as needed. Some people may also want to write primitives in FASM for Safety Forth. You can't put these in Safety Forth yourself, because you can't build Safety Forth without the source-code. You can give your FASM primitive to me though, and I will include it in Safety Forth (after first skimming through your code to make sure that it is not malware). BTW: Ville --- you never answered my question as to if your text editor is open source. This would allow me to modify it to be an IDE for Safety Forth. As I said, my major stumbling block is GUI programming, which is required nowadays for an IDE. Code: ; The cell is 64-bit. Numbers are 64-bit fixed-point, with unity=2^32. ; Pointers are 32-bit (the integer part of a number). This is distinct from an address, that is 64-bit. Usere don't work with addresses. ; Pointers are negative offsets from RDI that is our base address. This gives us 2GB maximum for all manner of data. ; It is illegal for the user to access memory through non-negative pointers. The words @ ! etc. will abort on a non-negative pointer. ; Everything that we want to not accidentally be corrupted is in non-negative memory so a program with bugs won't write to it accidentally. ; Threaded code is in non-negative memory. An XT (execution token) is 16-bit. ; NEXT shifts an XT left by 4 bits to make it a non-negative pointer into 1MB of code memory. ; The size of the threaded code could be made larger with a minor rewrite, but 1MB seems adequate (UR/Forth had 64KB that was inadequate). ; EXECUTE takes a 16-bit XT. It will abort if given any unsigned number >= 2^16. ; This is ITC (Indirect Threaded Code). The cfa is a 64-bit address that points to machine-code memory (not user accessible). ; All of the primitives (machine-code) are written in FASM and built in to the system. The user can't write his own primitives. ; The memory map looks like this: ; ------------------------- ; system variables and headers 1/4 MB ; ------------------------- ; return stack 1/4 MB ; ------------------------- ; double-cell data stack 1/8 MB ; ------------------------- ; single-cell data stack 1/8 MB ; ------------------------- ; threaded code 1 MB required, and it has to be just above 0 ; 0 ------------------------- ; static data 1/4 MB, has to be negative ; ------------------------- ; heap 1 MB, has to be negative ; ------------------------- ; The user may find it confusing to have negative pointers, as most Forth systems use unsigned pointers. ; The reason Ido this is that NEXT uses LODSW that zero-extends the 16-bit XT into RAX for a non-negative token. ; If we had threaded code in negative memory, NEXT would need to do a NEG that would slow it down. ; Also, we want 0 (typically used as a null pointer) to be an invalid pointer that @ and ! will abort on. use64 ; In the following, we are using the term "word" to mean an 8-byte value; this is contrary to x86 assembly-language terminology in which "word" means a 2-byte value. b equ 1 ; size of a byte (8-bit) h equ 4 ; size of a half-word (32-bit) w equ 8 ; size of a word (64-bit) reals, strings, pointers, xt, and IEEE-754 double-precision floats d equ 16 ; size of a double word (128-bit) dreals, ratios and BFIs --- a BFI ("big f'ing integer" is 128-bit with a unity of 1) paragraph equ 10h ; the decoder converts paragraph-sized chunks of code into trace-code page equ 40h ; size of a cache line, for both data and code (on the newer processors; the older have only 20h) KB equ 400h ; kilobyte MB equ 100000h ; megabyte GB equ 40000000h ; gigabyte ; register dedications ; rax ; general purpose ; rbx ; top value of single-wide stack ; rcx ; general purpose ; rdx ; general purpose ; rsi ; interpretive pointer ; the DF flag must be cleared (0) at all times ; rdi ; base pointer ; an address, not a pointer ; rbp ; return stack-pointer ; an address, not a pointer ; rsp ; single-wide stack-pointer ; an address, not a pointer str equ r8 ; top value of the string stack strlo equ r8d ; the low half-word of STR --- where the count is (the ptr is in the high half) cnt equ r9 ; the CNT user-register ; an integer in CNTLO (top half not used) cntlo equ r9d ; the low half-word of CNT ptr equ r10 ; the PTR user-register ; an address, not a pointer frame equ r11 ; locals stack-frame for colon words ; an address, not a pointer lo equ r12 ; low word of top value of double-wide stack lolo equ rl2d ; the low half-word of LO hi equ r13 ; high word of top value of double-wide stack hilo equ r13d ; the low half-word of HI ss equ r14 ; string stack-pointer ; an address, not a pointer ds equ r15 ; double-wide stack-pointer ; an address, not a pointer ; The lower 8 registers can be used without a REX byte, so the code is smaller. ; RSI has to be the instruction pointer so LODSW LODSD etc. can be used (and DF has to be 0 to progress upwards). ; RSP has to be the single-cell data-stack pointer so PUSH and POP can be used. ; Don't use RBP or R13 as the base register in a LEA, as this is slow (according to the Intel optimization manual page 3-31). ; Also R12 takes up an extra byte of memory in the code. ; The string instructions can't be used without saving and restoring the registers being used. In general, don't use them. macro next1 ; doesn't affect flags { lodsw ; AX zero-extended into RAX and RSI advanced } macro next2 ; affects flags { shl rax,4 ; shift RAX to a paragraph (all functions are paragraph aligned) } macro next3 { jmp qword [rdi+rax] ; jump through the cfa (contains the 64-bit address of the machine-code) } ; The threads are 16-bit, but are shifted left 4 bits, so they are offsets into a 20-bit (1MB) section of memory for threaded code. ; All functions must be paragraph aligned because we assume the lower 4 bits are zero (after NEXT2) ; 1MB should be adequate for all of our threaded code. If not, there are alternate schemes that provide more memory. ; There is a 64-bit cfa at the front of each function. This is followed by 16-bit threaded code. ; The 16-bit threaded code is about 1/4 the size of 64-bit threaded code. This should reduce data-cache thrashing. macro next ; this can be put at the end of primitives to terminate them (instead of the RTS used in typical asm code) { next1 next2 next3 } ; Instead of using NEXT it is possible to use NEXT1 NEXT2 and NEXT3 explicitly, with code between them. ; This may boost speed because it helps them parallelize with surrounding code. ; If literal data is obtained with LODSD this must be done prior to NEXT1 being done. Any use of RAX must be prior to NEXT1. ; RAX and RDX are used by multiplication and division instructions, so be careful. ; My understanding of the x86 is that data-cache thrashing is the primary cause of slow execution speed. ; This is why I have 16-bit threaded code: reduce the data-cache thrashing and boost the speed. Yay! ; This may or may not work. I also have a three-instruction NEXT, which is pretty lengthy. My slow NEXT might ruin the speed. ; In the Pentium, LODSW was slow. It is supposed to be fast in modern processors though. ; "Optimization" is all speculation. Nobody knows what the x86 is doing internally. Trace code is proprietary to the chip maker. _________________ When all else fails, write the source. |
|||
|
15 Sep 2020, 20:11 |
|
|
Ville 18 Sep 2020, 11:15
Many applications sources are at the download area (of menuetos.net), not the text editor though. I personally write asm-sources at the editor and then use a separate fasm-app for assembling.
|
|||
|
18 Sep 2020, 11:15 |
|
|
Hugh-Aguilar 19 Sep 2020, 03:57
Ville wrote: Many applications sources are at the download area (of menuetos.net), not the text editor though. I personally write asm-sources at the editor and then use a separate fasm-app for assembling. Forth traditionally provides an interactive development environment. It is possible to test functions individually on the command-line (similar to the REPL in Lisp which is like the Forth outer-interpreter). Writing this IDE is the problem for me because I don't know anything about GUI programming. Your text editor can be used for writing Forth source-files. These can then be loaded with the INCLUDE command from the command-line. Most text editors provide a way to call them with a file name, and a location in the source-file for the cursor to start at --- this is useful for cases in which INCLUDE aborts with an error and the user wants to go to that spot in the source-file where the problem occurred --- presumably your text editor does this. When I was at Testra, I did write a Forth cross-compiler that did not have an IDE and was not interactive. This was similar to a C cross-compiler in that it took a source-file and produced an executable, but the executable had to be debugged with a debugger --- interactive debugging of individual words was not allowed. Debugging like this is much more difficult that debugging interactively --- after I left Testra, a traditional interactive Forth system was written using my cross-compiler, so users could run Forth on the target system. BTW: That design I showed earlier had a security problem. I'm surprised that you guys didn't jump on that! A malware writer could purposely overflow the data-stack to modify the threaded-code region that he is supposed to not have access to. This is my new slightly modified design: Code: ; The data memory map (base RDI) looks like this: ; ------------------------- ; system variables and headers 1/4 MB ; ------------------------- ; return stack 1/4 MB ; ------------------------- ; double-cell data stack 1/8 MB ; ------------------------- ; single-cell data stack 1/8 MB ; 0 ------------------------- ; static data 1/4 MB, has to be negative ; ------------------------- ; heap 1 MB, has to be negative ; ------------------------- ; The stacks and headers are in non-negative memory to prevent them from being corrupted by a program with bugs. ; ; The code memory map (base RCX) looks like this: ; ------------------------- ; threaded code 1 MB required, and it has to be just above 0 ; 0 ------------------------- ; The code memory has RCX as the base, and the user has no way of finding out what RCX is. ; None of the functions that access memory using RDI as a base can be used to access the threaded-code. Code: ; register dedications ; rax ; general purpose ; rbx ; top value of single-wide stack ; rcx ; code memory base ; an address, not a pointer ; rdx ; general purpose ; rsi ; interpretive pointer ; the DF flag must be cleared (0) at all times ; rdi ; data memory base ; an address, not a pointer ; rbp ; return stack ; an address, not a pointer ; rsp ; single-wide stack ; an address, not a pointer gp equ r8 ; general purpose cnt equ r9 ; the CNT user-register ; an integer in CNTLO (top half not used) cntlo equ r9d ; the low half-word of CNT ptr equ r10 ; the PTR user-register ; an address, not a pointer frame equ r11 ; locals stack-frame for colon words ; an address, not a pointer framelo equ r11d ; the low half-word of FRAME lo equ r12 ; low word of top value of double-wide stack lolo equ rl2d ; the low half-word of LO hi equ r13 ; high word of top value of double-wide stack hilo equ r13d ; the low half-word of HI ss equ r14 ; string stack-pointer ; an address, not a pointer ds equ r15 ; double-wide stack ; an address, not a pointer Security is more complicated that I had expected! I have to think like a malware-writer, which is totally out of character for me. I will make it secure though. _________________ When all else fails, write the source. |
|||
|
19 Sep 2020, 03:57 |
|
|
Ville 21 Sep 2020, 13:25
I wrote a simple text editor, sources below. You can use it however you like. Also the Menuet disk image contains examples for other GUI operations.
|
|||||||||||
|
21 Sep 2020, 13:25 |
|
|
Hugh-Aguilar 21 Sep 2020, 19:22
Ville wrote: I wrote a simple text editor, sources below. You can use it however you like. Also the Menuet disk image contains examples for other GUI operations. Thanks! 
This should be a huge help! I may still have the programmer use your closed-source full-featured text-editor for editing large source-files. This simple text editor should be adequate for interactively debugging small code snippets in the IDE. _________________ When all else fails, write the source. |
|||
|
21 Sep 2020, 19:22 |
|
< Last Thread | Next Thread > |
Forum Rules:
|