|
My brain is built of paths and slides and ladders and lasers and I have invited all of you to enter its pavilion. My brain, as you enter, will smell of tangerines and brand-new running shoes.
| Sunday, February 22, 2009 |
  Captain's Log, Stardate 0x47EB | 
Posted - 2/22/2009 4:48:04 PM | Took a couple of hours today to clean up the disassembler table a bit and make it nice and formatted-looking. I also took some common instruction sequences and extracted them to "meta-instructions" to reduce the amount of duplication in the table. Overall I'm pretty happy with the results.
Aside from general tweaking and improvements in the utilities, I've started converting everything from a text menu driven format to a more traditional command-line format, with switches and parameters and all that good stuff. This gives us two advantages: first, it's much easier to use the utilities as a group since we have the option of doing things like batch files and so on. Secondly, it makes it much simpler to invoke the tool from the IDE.
I'm actually collapsing both FugueASM and FugueDLLClient into a single utility, FugueShell. This app will serve as a general jumping-off point for any of the typical Epoch work: compiling, assembling, disassembling, running source code (or binaries), assembly code formatting, and so on. I like this setup because it makes it simpler to remember how to use the tools. It also makes it trivial to support things like batch code formatting, batch compiling, etc.
So all in all today's work is primarily just making things more robust and accessible. I'm trying to stick to a pretty simple set of principles on this project:
- Get it working as soon as possible - then release it
- When things need improvements, make them immediately - then release them
- Always aim for the goal of writing real production code in Epoch
Everything is filtered through these three pragmatic rules. While it means that occasionally development of language features will slow down for a time, it also means that we should always be no more than 1 release away from well-polished, powerful, and accessible tools - tools which can be used for real world applications.
| |
| Some Disassembly Required | |
Posted - 2/22/2009 1:01:03 AM | Alas, I spent most of the day off in the Big Blue Room having one of those "social life" thingies, so I didn't get a huge block of time to hack on Epoch today.
However, I did manage to get the table-driven disassembler finished; the same blob of macro magic now powers both the assembler and disassembler. In there somewhere I got sick of reading flat EASM files, so I wrote a quick pretty-printer that automatically indents the files. Unfortunately, the presence of whitespace totally confuses the assembler/disassembler code, so I'll have to shore that up a bit.
My next thing to tackle is factoring out common sequences in the assembly table. For example, there's a delicate way that begin-scope instructions have to be handled; at the moment, every time I read into a new lexical scope, I have to do some juggling to make sure things get written out correctly. Let's just say that the order of instructions surrounding a lexical scope entry is... quirky. So one thing I can do is factor that bit of juggling out into a meta-instruction in the assembly table.
I can practically smell all the dark voodoo that's oozing out of this assembler, but it's been a fun little diversion from the main language efforts 
| |
| Saturday, February 21, 2009 |
| Epoch Task List | |
Posted - 2/21/2009 2:54:28 AM | Latest Progress
I've finally managed to get the table-driven implementation of the assembler working smoothly; apparently there are a lot of weird corner cases in my assembly language 
The plus side is that it's now much simpler to extend the assembler. The downside is that I'm still working against the reference disassembler that shipped in Release 5 - I still have to convert it over to the table-driven system. To make things nice and interesting, I also seem to have broken the binary loader, so very few parts of the Epoch toolchain are actually usable at the moment.
Thankfully, with the practice I've gotten on the assembler side of things, converting the disassembler should go pretty fast. The table is already set up and correctly assembles the language, so operating it in reverse mode shouldn't be too difficult.
Along the way I got tired of reading flat EpochASM files in Notepad, so I threw together a simple pretty-printer that indents the ASM code when new scopes or code blocks are entered. This made a huge difference in tracking down the last few bugs in the assembler table; I'll probably end up polishing it up a bit and integrating it with the FugueASM tool.
Task List
As promised earlier, here's my current working to-do list for Release 6:
Critical Features
- Finish binary deserializer in Fugue
- Implement short-circuiting on logic operators
- Finish some corner cases in nested structure accessing
- Improved syntax for initializing structures
- Allow libraries to register constants, externals, etc.
- Fix bug where compiled EXEs do not terminate correctly
- Fix remaining hard-code offsets in Exegen
Code Cleanup/Refactoring
- Finish use of DetermineEffectiveType() in ParserState::CreateOperation()
- Examine binary loader in Fugue for simplifications
Code Rewrites
- Convert disassembler to table-driven system
- Examine built-in operation loader for possibilities to use tables there as well
Nice To Have
- Buffer entity (stack/heap)
Era - The Epoch IDE Project
- Convert existing tools to CLI format
- Extend resource compiler to support menus, dialogs, etc.
- Create a basic shell window with necessary menus
- Add rough editing capabilities
- Implement support for Epoch programs implemented across multiple files
- Refactor IDE code into modules once this is available
- Update IDE to handle "projects"
- Implement REPL
- Implement resource editors in the IDE
So obviously there's a huge amount of stuff to be done, and we're not likely to see Release 6 for quite a while.
| |
| Friday, February 20, 2009 |
| Adventures in Assemblers | |
Posted - 2/20/2009 5:10:21 PM | Epoch Q&A
Thanks for everyone who's posted for the Q&A. I'm still considering it open, so fire away with all those questions. See the post a couple days prior to this one for the current set of questions and answers.
Current Status
There's something I've wanted to do ever since I wrote the first EpochASM assembler - rewrite it completely. The implementation that shipped in R5 is pretty craptacular. It's literally a giant glob of if/else statements that test for each possible instruction and data combination.
What I've done is convert over to a table-driven assembler. The table basically amounts to a miniature language. Using #defines, the C++ compiler takes the assembler table and converts it to actual C++. This generated code then does the job of assembling (or disassembling) a program.
The generated code is nothing fancy - in fact, it's pretty much a carbon copy of the hand-written code, with some quirks due to the fact that it's all automatically generated. However, this is a major bonus for maintainability, because it's now trivial to add an instruction to the VM, and the assembler and disassembler automatically know how to work with it.
This leaves one piece that is still hand-coded, and that's the actual bytecode loader in the VM. Unfortunately, I can't think of a good way to automate that code, since it really all has to be capable of handling specific situations for each different instruction. There may be some low-hanging refactor fruit in there, though.
Only one problem with this grand adventure - the assembler quit working. Somewhere along the way I mistranslated a couple of rules, and now the disassembler and loader both fail to accept generated binaries. So my evening will consist of tearing apart the assembler again and trying to find exactly what went wrong.
Later on once things are working again I'll post up my current R6 to-do list.
| |
| Thursday, February 19, 2009 |
| A Glorious Victory for the Empire | |
Posted - 2/19/2009 5:42:49 PM | My biggest time sink over the last couple of days has been my new Epoch tool, Exegen (rhymes with oxygen). Exegen is a linker for Win32 Epoch programs. In essence, it automates the process of starting the VM and feeding it Epoch code.
To be specific, Exegen actually fabricates an .EXE file from scratch (hence the terrible name). This includes all the standard chunks that a modern .EXE has - actual code, text constant tables, resources such as icons and menus, and so on. My goal is to wrap this up along with the Fugue compiler and FugueASM tools, and produce a complete toolchain that can go from Epoch source to compiled .EXE automatically.
For those who aren't interested in the arcana of creating your own .EXE files, you can safely continue with the rest of the journal post. For everyone else, you can see the unfolding saga (and chronicles of my victory) over in this thread.
Now that Exegen works properly, I can start on my personal goal of generating a small program that includes an icon resource and a menu resource. This program will form the basis for Era, which is the codename for the Epoch IDE I'm going to start developing shortly.
Release 6 will consist of two major components: an updated and much improved VM implementation, and the Era IDE. My goal is to use the Era project as a way to find holes in the Epoch toolchain. Specifically, if I run into things that Epoch (or its tools) can't handle, I can fix them up for R6. This pretty much guarantees that R6 will be robust enough for fairly serious Win32 development.
Even though R5 technically works for doing Win32 programming, it kind of sucks and is annoying to use. In R6, all the tools will be designed to be run from the command line, or via Era. I will probably be creating a simple "project file" format which Era can use to run all the tools to go from text source to final .EXE.
So that's the state of Epoch. Due to Real Life I may or may not be able to get some more stuff done over the weekend; in any case I'll be back soon with more updates.
Stay tuned, and don't miss our Q&A post from earlier in the week - I'm still open for questions!
| |
| Monday, February 16, 2009 |
| Resource files suck | |
Posted - 2/16/2009 9:11:18 PM | Status Update
My big challenge at the moment is to finish the part of the toolchain that builds a final wrapped .EXE program from Epoch source code. I have the rest of the toolchain in place, and used some dirty hackery to generate my test .EXEs; however, this time I'm aiming to do it right and generate an actual custom-tailored .EXE for each Epoch program.
The .EXE trick works by loading the Epoch bytecode into a data section of the .EXE, and then passing that block of memory off to the Virtual Machine to execute it - a fairly standard practice.
Where things get messy is including resources in the .EXE file. Resources take up space, which screws with offsets and all that good stuff. So in order to support resources in Epoch .EXEs, I have to essentially write a resource compiler that can update the relevant .EXE fields to point to the Epoch code, without disturbing the resource data.
I've been banging my head against the Win32 compiled resource format, particularly with icons. So far I haven't gotten much in the way of results, but the night is young...
Epoch Language Q&A
I've been meaning to do this for a while, so here we go. I keep getting comments on the Epoch posts and missing the questions/feedback people leave. (I will gently blame the journal software for this.) So what I'd like to do is take a dedicated post to just answering questions and feedback.
If you have any thoughts at all on the Epoch project - including, but not limited to, "shut up and talk about something different already" - just drop a comment on this post. I will monitor it for activity and update it with answers as time permits.
Quote:Original post by Falling Sky
How about support for embedded system programming? |
In theory there's nothing that should stop you from using Epoch in an embedded environment; however, true support requires writing a cross compiler for the target platform, or at the very least a compiler that outputs C. I wouldn't rule out seeing an Epoch->C compiler arise at some point, but it's not on my priority list. I'd welcome anyone who is willing to write one, however
Quote:Original post by visage
How do you plan on a) allowing the user to give the compiler hints (syntactically) without things getting too cluttered and b) keeping the system extensible? |
There's two parts to this. One half of the design is for a general task block, which splits off a parallel line of code which executes the contents of the block. Synchronization between tasks can be accomplished via a built-in lockless message queue. Tasks are only designed to be parallel to the main code body (and each other) - the language does not specify how this is implemented.
This brings us to the second half of the architecture: parallelism plugins. We can put a tag on each task block to have it handed to a given plugin. The default is to use the base platform's existing threading support; however, any other type of parallelism can be implemented in this way.
For example, we might run across a block such as task (gpu) { ... }. This will look in the compiler plugins for a parallization server called gpu. This server will be fed the raw Epoch code, and is responsible for emitting the actual shader instructions. Additionally, there is a runtime plugin which registers with the VM, and takes care of actually running the shader and returning the result data to the Epoch program. (Of course this will have analogous support in other compilation models; native code, .NET CLR, or whatever else we end up with.)
Quote:Original post by Mike.Popoloski
Your latest post talks about creating an IDE. I think it might be simpler to take advantage of the Visual Studio shell and create a language on top of that. Have you considered that option? |
To be perfectly honest, I've tried the Visual Studio extensibility features (via the official SDK) and found them to be pretty much, well, shit. Visual Studio is incredible over-engineered. Yes, you can do virtually anything, down to writing your own syntax highlighter and debugger features. However, actually getting that done is ridiculously complicated.
Seriously, if you've never played with the VS SDK, you should try it out - it's a great object lesson in how not to design extensibility systems.
There's a couple other reasons I'm doing my own IDE. First of all, it means I can specially create everything to deal with working with Epoch. A tailor-made IDE can be a very useful thing; see Smalltalk. What I'd really like to do is build the IDE around a REPL (read/evaluate/print loop) which facilitates rapid prototyping, etc.
Secondly, having a standalone IDE means I don't have to worry about whether or not people have Visual Studio. As far as I am aware it isn't possible to extend the Express Editions of VS with new languages. This instantly cuts my user base down to people who have a full version of VS. Since my goal is maximum exposure, locking myself into an expensive (and fairly rare) product would be suicidal.
Finally, I'd like to see Epoch become like BASIC used to be back in the '80s, where just about anyone can sit down and fool around with the language. The .DLL that contains the Virtual Machine doesn't just execute Epoch bytecode; it contains a compiler that produces .easm files. To start writing your own Epoch programs you don't even need to download additional tools - any program written in Epoch automatically gives you the ability to write your own code.
I'm doing this entire project in the spirit that I would like to see Epoch become accessible, powerful, friendly to newcomers, and most of all, as open as possible.
There's also the fact that a language IDE written in its own language is pretty darn cool  Plus, as I mentioned in the aforementioned post, it will show me lots of areas where the language isn't ready for prime-time yet, and give me a chance (and reason) to shore those areas up.
Quote:Original post by evolutional
Question for the Q&A: Will Epoch be targetted specifically for writing standalone apps or will it be embeddable within an application for user scripting? Additionally, what about the ability to create Epoch Dlls that can be imported as modules in Epoch programs (or even referenced by external apps?). |
The Epoch virtual machine can be used either as a fully standalone system, or in tandem with another running language. Embedding Epoch is a bit messy at the moment, but totally possible. If it proves to be a high-demand feature, I'll clean it up a bit and add some features to make it even more robust and useful.
As far as multiple-file Epoch programs (including multiple source files and source files + libraries) I haven't done much planning yet, but eventually it should be trivial (for the user) to write Epoch libraries that can be used by Epoch directly or by other languages via the C marshalling layer.
| |
| Sunday, February 15, 2009 |
| Epoch Release 5 is here! | |
Posted - 2/15/2009 8:39:58 PM | OK, I'm a lying little bugger and should be viciously and repeatedly punched in the face.
I decided to go ahead and package up R5 tonight. There's really not much left that needs to be implemented - at least, nothing that's worth delaying the release.
As mentioned in my previous post, R6 will basically be just cleaned up and improved code from the VM perspective. The only really major "new" thing will be the IDE prototype app, which will ship with R6. That lets me shift gears a bit and really buckle down on the remaining fixes and improvements I want to make. Without the distraction of shiny new features to work on, I should hopefully manage to crank out R6 fairly quickly.
Release 5 is a huge deal all by itself, because it introduces so many new features and concepts. I'd really appreciate any feedback on the release - especially if you find cases where things don't work as expected. There should be plenty of sample code to get you started, and the syntax is very simple, so that shouldn't pose a huge challenge.
So, the moment you've all been waiting for: Epoch Release 5 (.RAR, 336KB)
| |
| Guess what I'm gonna talk about! | |
Posted - 2/15/2009 5:27:22 PM | I started implementing bitwise operators in Epoch this afternoon, and stumbled across a couple of massive refactorings that I'd like to do. The specifics aren't interesting, but the bottom line is I can make the instruction-emitter part of the compiler work much more efficiently and consistently, especially when it comes to built-in functions.
So today will likely end up being one of those days where you have a net loss of code (in terms of KLOC or whatever stupid metric you want to throw around) even though the codebase is now much cleaner and more flexible.
Thankfully, the only pressure I have on the project is to have a working release ready by GDC, so I can pimp it out to anyone I run across. That leaves me a little over a month to cram whatever awesomeness I can into things.
In terms of Release 5, I still want to grind through as much of the checklist as I can, and make sure all the example code is up to par. That's going to be a fairly tedious job as I'm sure there will be a lot of instructions that aren't properly handled by the assembler, or the disassembler, or the actual VM runtime.
Building the binary compiled code was a lot of fun, but the downside is it has introduced a series of potential gaps in the implementation. Keeping all the instructions and routines in sync can be a pain... there's the instruction emitter code in the compiler, the instruction evaluation and encoding routine in the assembler, the decoding and pretty-printing logic in the disassembler, and the decoder that loads the bytecode into the VM. So many points of failure, so little time...
I can't decide how much refactoring and general code cleanup I want to try to do for R5; it really depends on what I decide to tackle for R6. At the moment I'm thinking R6 will basically consist of the first rough build of the IDE, plus whatever additions/improvements/refactorings I can find (or end up needing) in the toolchain.
So... all this gibberish to say, I'm tentatively aiming at making Release 5 within the next week.
| |
| Saturday, February 14, 2009 |
| Bugs are crunchy. And good protein. | |
Posted - 2/14/2009 7:47:00 PM | Amid a horde of distractions, I managed to hunt down and viciously kill the stack corruption bug. There were actually several minor bugs that all conspired to drag me out into undefined-behaviour-land.
The specifics aren't really interesting to anyone who isn't deeply familiar with the VM code (which, I assume, means nobody). However, the upshot is that nested structures work properly now.
There are a couple of minor things I'd like to do to make the syntax a little cleaner, but they should be fairly trivial additions at the grammar layer. Most of the syntax is going to remain ugly until I get around to designing the "syntax sugar" layer that will go on top of the current syntax.
So, the updated R5 checklist follows:
Requirements for Win32 Programming
Named constants
Hex literals
- Bitwise operation instructions
- Byte buffer entity
Additional TODOs
Implement nested structure marshalling (C to Epoch)
Implement function pointer marshalling (C to Epoch)
Fix flaky STDIO pipes between FugueDLLClient and FugueASM
Type validation for readstructure function
- Test all example programs for assembling and binary execution
And of course the wishlist
- Better syntax for initializing nested structures
- Ability to write entire structures into nested structures
- Allow libraries to register EXTERNALs and structure types
0239 - I seem to have contracted a bit of insomnia (probably related to the multiple cans of Mountain Dew consumed earlier) so I'm hacking a bit more on things. My latest victory is the final set of type-safety checks for the readstructure() function. I think I'll have a change of pace and work on something besides the structure code for a while... named constants seem like a worthy foe.
0315 - found some more type validation bugs along the way, and fixed them up; named constants are now implemented. For the moment only a built-in type can be a constant, and constant members of structures/tuples are forbidden. I can't think of any reason to change that, at least for now, and it makes parsing a bit cleaner. Now onwards to hex literals!
0347 - hex literals are finally working. It took a bit of wrestling with boost::spirit, which likes to be really cranky sometimes. The real problem is, every time I need to tweak the parse grammar, it takes over a minute to actually compile. This means every change has a significant turnaround time, especially when I get distracted during that minute-long build.
0537 - it's hard to describe the last two hours without resorting to profanity. I've been deeper into the guts of the Win32 console system than I ever thought I'd go. I've been across the internet and back again in search of answers. I crawled on my battered, bloodied hands and knees through the desert of uncertainty, the blazing sun systematically charring every inch of my broken body. But I finally got the input/output pipe to work correctly, which means you can launch the FugueASM assembler directly from the FugueDLLClient shell app. Wheeze.
0622 - the past hour has consisted mostly of me trying to decide whether or not to go out and grab some breakfast. In between that and trying to freeze to death, I've gotten the marshalling code finished for the remaining two cases, function pointers and nested structures. Function pointers are not allowed to change during the course of an API call, because I'm too lazy to figure out what that means and how to adjust the VM to reflect the change. So there.
| |
| The Chronicles of Epoch | |
Posted - 2/14/2009 2:37:09 PM | Spent a few minutes earlier playing around with what I thought was the finalized version of nested structure support... and then I discovered a pretty serious bug. Somehow, the stack management is getting out of sync with the actual instructions, and the code is reading and writing data in effectively random places on the stack.
This means we get interesting effects like assigning "test" into a structure's string member, and getting back the string "hello universe" when we read the field back again. The string "hello universe" is used in a totally different part of the code - not even the same function. Oops!
So my day today will probably consist mainly of tracking this thing down and killing it.
| |
| Thursday, February 12, 2009 |
| Epoch status report | |
Posted - 2/12/2009 4:45:45 PM | As of 1650 hours today, this is where the release task list for R5 stands:
Requirements for Win32 Programming
- Named constants
- Hex literals
- Bitwise operation instructions
- Byte buffer entity
- (Some fixes to nested structures)
Major implementation items
FileLoader::LoadScope needs tuple and structure support
Finish CallbackInvoke; accept more return types
Additional TODOs
Clean up memory leaks in deserialization code
- Implement nested structure marshalling (C to Epoch)
- Implement function pointer marshalling (C to Epoch)
Add support for named function signatures as function parameters
Examine Block::ReverseTailOperations for refactorings
- Fix flaky STDIO pipes between FugueDLLClient and FugueASM
- Test all example programs for assembling and binary execution
Serialize the global-variable initialization block
And of course the wishlist
- Better syntax for initializing nested structures
- Allow libraries to register EXTERNALs and structure types
I'll be spending the evening attacking various items as I go along; watch this space for updates!
1747 - completed memory leak fixes for deserializer
1833 - finished support for named function signatures as parameters
1838 - finished some refactorings
2024 - finally got structure and tuple support implemented in the deserializer; found and squished quite a few bugs along the way
2056 - started to work on serializing the global initializer block, but encountered some weird bugs. Will investigate a little bit more and then probably call it a night.
0008 - after taking a break for some Real Life™, I've gotten back on the trail of this mystery bug. Turns out I forgot to allocate storage for global variables, meaning they were being stored on the stack and then obliterated when code started to run. A relatively easy fix later, and I've knocked out another task.
0012 - added the remaining function return types to support in CallbackInvoke; i.e. now callback functions can return different types to the caller instead of just integers. There is the __stdcall-imposed limit of 32 bits in the EAX register, of course.
0022 - after having spent five entire minutes looking blankly at the code and trying to remember what I was doing, I've decided it's time for bed
1258 - following a great night's sleep I've gotten back into things. So far I've fixed a couple major bugs and managed to get nested structure support improved a little bit. Further improvements to nested structures are coming later today, after I grab some lunch and decide on how exactly I want the syntax to look.
1839 - I've spent most of the afternoon trying to get nested structures to work the way I want them to. It took a few false starts but I finally hit on a possible solution (which, as often happens, is incredibly simple, clean, and elegant - and ridiculously obvious).
2030 - it looks like we're down to the final touchups on getting nested structures sorted out. There are still some corner cases that are messed up, but they should be easy enough to take care of. For now, I'm going to go pretend to have a social life - hell, it is Friday night
| |
| Wednesday, February 11, 2009 |
| Epoch makes history! | |
Posted - 2/11/2009 11:48:44 PM | It was quite a ride, and involved far more use of hex editors and obscure console commands than should be legal, but I've finally got it working - it is now possible to embed Epoch programs inside a stub EXE, allowing you to run purely from binary form - no source code required.
Give it a shot. It's not a particularly exciting demo, but it gets the job done, with a nod to programmer tradition.
This officially means that Release 5 is coming down the pipe Soon™. I still have a lot of minor things to do, of the pesky little "TODO" variety. There's still a solid amount of work to be done in order to get this thing in good shape for a release, so it may take some time. All the big hurdles are fully cleared, though.
One particular problem is that when you run the generated stub EXE, you don't get an output console. This means that if the program does nothing but read/write to and from the console, it basically just sits around being invisible. I'm not sure how to fix this off the top of my head, but it can't be too drastic.
In any case, I am officially verging on brain-dead for the day, so enjoy your little slice of Epoch and hold on tight for R5!
| |
| Your daily dose of Epoch | |
Posted - 2/11/2009 3:07:45 PM | Not much to say, just wanted to note that I've finished the disassembler (aside from a few obscure instructions I haven't added yet).
This gives us five major tools for working with Epoch:
- The Fugue virtual machine
- EpochASM assembly language for the VM
- Compiler that translates raw syntax into EpochASM
- Assembler that converts EpochASM to binary
- Disassembler that regenerates EpochASM from binary
One last big hurdle remains, which is implementing the ability to directly execute binary from the VM, rather than just source code. Once this is in place, it should be pretty straightforward to generate EXEs.
Release 5 is slated for soon after I get EXE generation working. R5 will mark the first release of Epoch that is fully suitable for writing standalone programs that can be distributed easily.
After R5 my big goal is to start working on the IDE. For now I'm actually going to leave text editing alone and focus on the toolchain; so the IDE will start out as primarily a graphical way to interact with the VM, execute code, and so on. Of course the IDE will tap the features of the new assembler/disassembler as well.
Code editing with all the trappings of syntax highlighting, statement completion, et. al. will come later on. Preferably, that stuff will also be written by someone else
| |
| Yet another post about Epoch | |
Posted - 2/11/2009 12:59:51 AM | Spent the last couple of hours putting together an assembler for the VM bytecode format. This converts nice assembly language like this:
00DE4DD8 PUSH_INT 0
00DE4D58 PUSH 00DE43A0 INVOKE 00DD8D30
00DE5090 WRITE hInstance
00DE5D98 PUSH_INT 0
00DE5DF8 PUSH_STR 13 ScribbleClass
00DE5918 PUSH_STR 0
00DE5D50 PUSH_INT 6
00DE5B20 PUSH_INT 0
00DE5BD0 PUSH_INT 32512
00DE5C80 PUSH 00DE5618 INVOKE 00DDE3A8
00DE5A70 PUSH_INT 0
00DE5490 PUSH 00DE58D0 READ hInstance
00DE5820 PUSH_INT 0
00DE5678 PUSH_INT 0
00DE5EB8 BINDFUNC mywndproc
00DE5238 PUSH_INT 0
00DE5288 PUSH 00DE4F70 SIZEOF wndclass
00DE55D0 PUSH_INT 3
00DE4EC8 WRITE wc
00DE5740 PUSH 00DE4CF8 READ wc
00DE0310 INVOKE 00DD9720
00DE61F8 PUSH_INT 0
00DE5CC8 PUSH_STR 13 ScribbleClass
00DE6178 PUSH_STR 8 Scribble
00DE6500 PUSH_INT 13565952
00DE6548 PUSH_INT -2147483648
00DE62A0 PUSH_INT 0
00DE6610 PUSH_INT -2147483648
00DE6480 PUSH_INT 0
00DE60C8 PUSH_INT 0
00DE6110 PUSH_INT 0
00DE6590 PUSH 00DE6740 READ hInstance
00DE63C0 PUSH_INT 0
00DE62E8 PUSH 00DE6408 INVOKE 00DDAE48
00DE6898 WRITE hwnd
00DE68E0 PUSH 00DE6928 READ hwnd
00DE6A48 PUSH_INT 5
00DE69E0 INVOKE 00DDC2F8
... into a thoroughly unintelligible blob of binary.
Next up comes the disassembler which can convert back from the binary to a text format. This is intended to accomplish two things: first, to provide a way to validate the output of the assembler, and secondly, to allow people to reverse engineer Epoch programs for themselves.
The goal of all this binary mucking about is pretty simple: I'm going to design an .EXE stub that contains this binary code in a data segment. The stub simply loads the VM DLL, feeds it the binary, and sits back to enjoy the ride. Once the handover from the .EXE itself into the VM occurs, everything becomes 100% Epoch controlled.
This will, to put it simply, let you make .EXEs from Epoch programs. The only external thing they will require is the Fugue VM DLL, plus of course any libraries in use.
There's still a long way to go here; the binary code format cannot actually be executed yet, as the VM currently expects all of its programs in source form.
As soon as this .EXE stuff works, I'll start packaging R5. This is looking to be the single most radical update to the language yet. After the release, I plan to start working on an Epoch IDE, which makes it more convenient to write Epoch programs. More on that later; at the moment my brain is a bit cooked
(And yes, the IDE will be built entirely in Epoch.)
| |
| Tuesday, February 10, 2009 |
| Epoch, again. | |
Posted - 2/10/2009 4:02:51 PM | Took a bit of effort, but I've managed to implement if/elseif/else chains in the Epoch VM. This makes it substantially simpler to write complex conditional chains.
It may seem odd that something so simple took a lot of work; surely it's just a matter of popping a couple of conditional jump statements in, right?
Well, not really. The Fugue virtual machine is not a standard Von Neumann architecture: code is stored in a totally separate manner than data. There literally is no address system for the bytecode, so it's impossible to write a "jump to this instruction" operation.
Instead, I create a dummy layer that surrounds all the elseif() alternatives in a chain. This layer can be exited using the magic instruction EXIT_IF, which is automatically inserted after the end of each elseif() code block. So we have a mechanism that says "stop executing the current block/layer" which is functionally equivalent to a "jump out of the if chain's code area" instruction in a more typical architecture.
Aside from that, I've done a fair bit of bugfixing and some cleanup work. During all the renovation and screwing around, I managed to break or invalidate serialization in several ways, so fixing that is next on the list.
My big question now is where next to go with the language. On the one hand, there's a lot of features and functionality that remain to be implemented. On the other hand, doing any nontrivial coding in the language is a righteous pain in the neck.
So at the moment it's a toss-up between cramming more features in, and starting to build an IDE for the language.
I'm leaning towards the IDE project, if for no reason other than the fact that it'll be good to get some tools built - especially a debugger and disassembler that can step through the VM instructions. As a bonus, this will reveal any major missing functionality that is needed to do nontrivial Win32 apps; and I can use that information to prioritize what gets added.
In any case, things continue to shape up very nicely. And I'm still pumped that actual Win32 apps can be written in my own language...
| |
Page: 1 2 »»
All times are ET (US) |
In locus hic, omnes res dementes sunt.
|
| S | M | T | W | T | F | S | 1 | 2 | 3 | 4 | 5 | 6 | | | | | | | 13 | | | | 17 | 18 | | | | | 23 | 24 | 25 | 26 | 27 | | | | | | | | |
OPTIONS
Track this Journal
ARCHIVES
July, 2009
June, 2009
May, 2009
April, 2009
March, 2009
February, 2009
January, 2009
October, 2008
September, 2008
August, 2008
July, 2008
June, 2008
May, 2008
April, 2008
March, 2008
February, 2008
January, 2008
December, 2007
November, 2007
October, 2007
September, 2007
August, 2007
July, 2007
June, 2007
May, 2007
April, 2007
March, 2007
February, 2007
January, 2007
December, 2006
November, 2006
October, 2006
September, 2006
August, 2006
July, 2006
June, 2006
May, 2006
April, 2006
March, 2006
February, 2006
January, 2006
December, 2005
November, 2005
October, 2005
|
