If not now, eventually they must be or must have been "doing startups" because all businesses begin as startups. It's in the name, a startup is a company that is just getting started. Some eventually grow up into the titans of industry that we all know.
The parent is wondering why don't we see more entrepreneurs founding companies that look like they could become the next titans of industry. It seems to me that their companies either don't exist, or are currently invisible because they haven't begun gobbling up market share.
Most US authors pay only a few cents per delivery. [1]
Books with lots of images can become expensive but it seems like the images are likely unnecessarily big for an ebook, and that is why his costs are so disproportionately large.
Same here. The main design decision is how to represent the secondary stack. I was thinking we could reserve a pair of registers to keep the parameter stack pointer and return stack pointer, and swap them out with SP as needed.
1 2 + >r
becomes something like
SET PUSH, 0x1
SET PUSH, 0x2
SET A, POP
ADD A, POP
SET X, SP // back up data stack pointer
SET SP, Y // switch to return stack
SET PUSH, A
My first try would probably be to use SP for one stack and some other fixed register for the other stack. Also, traditional Forth interpreters don't use code like you showed. I think the main benefit of using Forth (unless you just happen to love RPN) is the compactness of the interpreted code. If you're not going to use an interpreter, then I'm not sure if Forth is really a win.
Edit: Just to clarify about the interpreter point, I'd expect something like "1 2 + >r" to be represented at run time as four words in memory and there'd be an interpreter, written in machine code, reading code word sequences and jumping to small bits of machine code to either do a built-in function or push the call stack.
What you've described is a threaded Forth, which is indeed the most common type of implementation. I was thinking about writing a subroutine-threaded (no inner interpreter) Forth that inlines common primitives and does some peephole optimization. Not necessarily as compact, but much faster. Forth still provides a flexible, structured programming environment compared to raw assembly, to say nothing of Forth's metaprogramming facilities. I'd also say that a fair amount of Forth's compactness comes from the programming style- lots of tiny subroutines allowing extensive code reuse.
That's interesting. Sorry for not getting it right away. It's making more sense on second reading. :)
Now I'm curious how you'd encode subroutine calls. Your example was completely inlined but the call-sequence will be critical in determining how compact the code ends up.
Also, were you thinking of using a cross-compiler and keeping the dictionary out of the DCPU-16s memory? Let me know if you create a public repo. I'd be interested to see what you come up with!
No worries, I should've been more detailed in my original post- what I'm describing is definitely an atypical (if not unprecedented) Forth. I agree, the call-sequence is critical. My initial thought was to ensure that we always leave the stack pointers in "return stack mode" before calling, and return them to that state before exiting a routine. Thus, procedures:
: A dup * ;
: B 2 A A 1 A ;
would look like:
A:
SET Y, SP
SET SP, X // switch to data
SET PUSH, PEEK
SET A, POP
SET B, POP
MUL A, B
SET PUSH, A
SET X, SP
SET SP, Y // switch to return
SET PC, POP
B:
SET Y, SP
SET SP, X // switch to data
SET PUSH, 2
SET X, SP
SET SP, Y // switch to return
JSR A
JSR A
SET Y, SP
SET SP, X // switch to data
SET PUSH, 1
SET X, SP
SET SP, Y // switch to return
JSR A
As you can see, a little bulky, but doable. Optimizing stack operations to make better use of the registers can get rather nasty- still thinking about the best way to approach it. I'm definitely thinking in terms of a cross-compiler, and ignoring things like defining words for the sake of simplicity, at least at first. I'll drop you a comment if I get a prototype working.
Oh yeah, you could whip a sweet little Forth system up for this processor.
The first thing to do is to write a DCPU-16 assembler in Forth, and use that to write the primitives. That's pretty simple -- just look at the 6502 assembler: http://www.forth.org/fd/FD-V03N5.pdf
Using a metacompiler with a Forth DCPU-16 assembler would be the best way to go. Then you could easily experiment with different threading schemes, stack architectures, etc.
I think you mean contracts or defensive coding. If someone calls my code wrong they will have to think to test that particular case themselves, which is hard. Unless I've written contracts; then when it blows up they'll know what they did wrong.
The question we have to answer to properly understand what went wrong is where did the argument originate. If it's being generated inside function A that then calls function B with it, a test of A should fail when it calls B with the wrong argument. In any case, I would imagine the test coverage in the A-B system is lower than it should.
I was a little disappointed that when he talked about Jekyll blogs, he didn't mention Octopress. The default theme looks pretty good, it has a decent set of plugins and the code display looks great. It was actually pretty easy to set up too.
Yeah. In this competition collaboration was discouraged. That does keep politics/alliance building skills out of the equation at the cost of worse overall final products.
