OSDev.org https://forum.osdev.org/ |
|
New esoteric programming language https://forum.osdev.org/viewtopic.php?f=13&t=14992 |
Page 1 of 1 |
Author: | AndrewAPrice [ Wed Sep 19, 2007 7:11 am ] |
Post subject: | New esoteric programming language |
I'm writing my own esteric programming language. It's extended upon Brainf*ck but with a few of my own ideas. - There is a stack that you can push to/pop from (using ^ and v). - There are If and While equivilents now (depends if you close the code block with ] (loop code block) or } (end of code block)). - You can declare functions. - You can include other files (like libraries). If you read over the specification, you might wonder what the c instruction is for. That's compiler specific and it's really up to compiler as to how it works. Once I make the H Standard Library that defines how things like file I/O should work, the library will be written in H as a wrapper around the c instruction (the standard library will be called by including "LIBRARY.H", pushing the paremeters onto the stack in reverse order, pushing 1 on to the stack, then calling the x instruction). The language (excluding the library) should be fairly complete - I'm working on an interpreter now. Code: The H Programming Language
--------------------------------- 19 September 2007 0.02 http://messiahandrw.netfast.org Execution Environment --------------------------------- The environment consists of at least 5000 units of memory storage and at least 512 units of stack storage. The environment begins with the all memory set to 0 and nothing on the stack. The pointer position begins pointing to the first unit in memory. A unit is at least 8 bits in length. The program begins executing from the first instruction and continues until there are no more instructions to execute. H Standard Library --------------------------------- To be implemented. --------------------------------- Execution Notes - Brainf*ck code should execute correctly without requiring modification. - If the pointer position is moved past beyond the bounds of the memory, then the pointer is wrapped around to the other side of the memory. - If a value has been decreased below 0 or increase above the maximum value stored in a memory unit, then the value is wrapped around. - If a closing nest is reached with no opening nest, then the debugger will be alerted in debug mode or the command will be ignored in release mode. - If a value is pushed on to the stack and there is no stack space remaining, then the value is ignored. - If a value is popped from the stack and the stack is empty, then the stack will return the value 0. - If a ( is executed, then the program will to the instruction after the next ). Code between ( and ) is not executed unless the function is registered and executed. - If a ) is executed outside of a loop, then the program will exit. - If a function is associated to a value already associated to another function, then the new value will be associated to the new function. - If a function is called with a value that is not associated with a function, the debugger will pause execution in debug mode, or the program will go to the next instruction in retail mode. - If unrecognised text is executed in debug mode, then the debugger will pause the code, or the program will go to the next instruction in retail mode. - The debugging command ! is ignored in retail mode. - The c command varies between implementations and therefore should not be used directly. The c command should only be used for testing and for writing implementation- specific function wrappers inside of libraries. - The ) and ] are identical, but should be used according to their context. - A function may also be ended with ]. Commands --------------------------------- -- Numeric Manipulation -- + Increase value pointed to by the pointer. - Decrease value pointed to by the pointer. > Increment the pointer position. < Decrement the pointer position. -- Program Control -- [ Opening nest. If value pointed to by the pointer is equal to 0 then jump to closing next. ] Closing nest. Jump back to opening nest. -- Stack -- ^ Push value pointed to by the pointer on to the stack. v Pop value from the stack in to the position the pointer is pointing to. -- Compatibility -- , Read byte from keyboard and place in to the position the pointer is pointing to. . Write the ASCII character of the value the pointer is pointing to on the screen. -- Functions -- ( Declare the beginning of a function. ) Return from a function. : Register the function of the last ( executed and associate it with the next number popped from the stack. x Execute the function associated with the next number popped from the stack. z Unassociate function associated with the next number popped from the stack. -- Preprocessor -- " Include the contents of the file named between two " over the position of the file name and the two "'s. # Ignore all text from and including the # to the end of the line. -- Debugger -- ! Pause execution until the debugger allows the program to resume execution. -- Compiler/Interpreter -- c Compiler/interpreter specific command. Change Log --------------------------------- version 0.02: - Removed { (do if 0) and } (end without loop) version 0.01: - Initial design documentation. |
Author: | Dex [ Wed Sep 19, 2007 1:52 pm ] |
Post subject: | |
Sounds interesting, theres a Brainf*ck interpreter for DexOS, let me know when its done, if i like it i may port it too, if thats OK. |
Author: | Pyrofan1 [ Wed Sep 19, 2007 4:00 pm ] |
Post subject: | |
who hasn't created their own esoteric programming language? Code: +a1?a50!a
|
Author: | Alboin [ Wed Sep 19, 2007 4:05 pm ] |
Post subject: | |
I think system calls would be cool: Code: 21 ^ #
Push 21(the system interrupt.) and have # call it. |
Author: | AndrewAPrice [ Thu Sep 27, 2007 12:46 am ] |
Post subject: | |
I've removed the { and } instructions since they are unnecessary. I'm trying to keep the language as 'minimal' as possible while being as flexible as possible. |
Author: | AndrewAPrice [ Thu Sep 27, 2007 4:25 am ] |
Post subject: | |
I've been working the compiler. Since bf code is valid H code, I've finished implementing all brainf*ck instructions into my compiler. Code: H Programming Language Compiler
http://messiahandrw.netfast.org Usage: h [options] source Options: -b <bits> Specify the size of the memory cells in bits. -cs Output to C# source code rather than a binary image. -d, --debug Generate debugging information. -h, --help Show this text. -l <language> Language to compile. -m <size> Number of cells in memory. -o <file> Specify output file. -O Disable optimisation. -u, --unsafe Generate unsafe code. Unsafe code is faster but does not provide memory protection. Supported languages: bf Brainf*ck (default) h0.02 H (0.02)(comming soon) Supported memory cell sizes: 8 8-bits 16 16-bits 32 32-bits (default) 64 64-bits My compiler can generate either Windows binaries or C# source (not fully supported yet because a 2MB bf program expands to around 90MB of C#!). I've also got basic optimisation, like merging multiple -,+,<,> into a single instruction at compile time. "--debug" does nothing for now. The number of memory cells can range from 1 all the way up to 2^64 (that means it can access from 8-bits up to a theoritcal 137,438,953,472 gigabytes of memory ((2^64) * 8 bytes))! I'm considering more optimisation tricks, such as merging + with -, and < with >, and replacing [-] with a set-to-0 instruction which should speed nearly every brainf*ck program up significantly! |
Author: | JamesM [ Thu Sep 27, 2007 5:05 am ] |
Post subject: | |
Looks good. If you can make a linux ELF-producing port I might port it to jimix as my first 'compiler'... I've now got bash history pretty much working and working on JTED - the jimix test execution daemon - will perform automated builds for different architectures then automated tests (forks, boots bochs/qemu quietly in the background, feeds input into the serial port and records output). This should tell me if I've buggered anything up when making code changes (it checks out my svn source automatically). Also putting in 'analysis' tests, that'll return CSV tables which get rendered by R scripts. So I'll be able to tell if I'm getting exponential performance (degradation) when forking processes or not... :S |
Author: | Crazed123 [ Sun Sep 30, 2007 3:04 pm ] |
Post subject: | |
Why do you want a personal dialect of Brainfuck? |
Author: | mystran [ Wed Oct 24, 2007 3:57 pm ] |
Post subject: | |
Isn't one of the major selling points of Brainfuck the ability to pack code really densely: since there are only eight instructions, every instruction will take only 3bits to store. |
Author: | Crazed123 [ Thu Oct 25, 2007 1:48 pm ] |
Post subject: | |
Well sure, but the actual code necessary to really accomplish anything will take *more* space than normal. |
Page 1 of 1 | All times are UTC - 6 hours |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |