rickman
gmail.com> wrote:> Jonah Thomas
gmail.com> wrote:>> If you don't have any jumps at all then it seems like the
>> instruction set might be simpler. You'd still be putting addresses
>> or relative addresses on the return stack to get the same results,
>> and it might likely not be as efficient, but removing those opcodes
>> might be worth something.
>>
>> As this group has discussed repeatedly, you can do
>> ... IF ... THEN ;
>> with just a conditional return.
>>
>> ... ?EXIT ... ;
>>
>> You can do IF ELSE THEN doing things that look inefficient in
>> high-level code but that don't have to be so bad.
>> ... IF A B C ELSE D E F THEN ...
>> ... ['] ABC >R ?EXIT RDROP D E F ...
>
> Yes, you can do this, but what did it buy you? In your IF construct,
> you need two branches which can be relative with small instruction
> space impacts because the destination is relatively close to the
> branch. The conditional exit has to set up the address to ABC which
> is not likely to be as local as the jumps requiring more instruction
> space. This also requires extra instructions for the stack
> manipulation. I expect that this not only is less efficient in time,
> it uses additional instructions in program memory.
>
> What is the advantage of removing the JUMP instruction? You can say
> the instruction set is "simpler", but to what end? Does this run
> faster, no. Is it more efficient in program size, no. What is the
> point?
I expect you're right. If it's a step toward having say 16 instructions
instead of 32 then that might be some value, or if there's some
instruction you don't have room for that would be better than a jump.
But this probably costs space and time and energy all three, the
processor has to do extra work and all you gain is one complication gone
inside the processor.
>
>> You could do a lot with a command that conditionally skips one
>> instruction and executes the next, or else executes one instruction
>> and skips the next. When either of the conditional phrases is one
>> instruction it's efficient. And either of them could be an
>> unconditional call. Would that, plus unconditional relative and
>> absolute calls and RDROP, be enough to satisfy every possible
>> branch? I think it might be, at some cost in efficiency.
>
> So why do you want to lose efficiency?
I like the idea of making it as simple as possible, but no simpler. I'm
not sure how to do that. Sorry to waste your time with things that don't
help.
>> Probably somebody has gone through all the possibilities and shown
>> that they just don't work well enough to replace what we already do.
>> But I haven't done that. Sometimes I want to.
>
> I doubt that anyone has done an exhaustive survey of this sort of
> method. But I don't see where it has any potential of working
> better. The JUMP instruction is a single cycle in a simple machine
> (not counting any prefixes). Pushing the address of JUMP onto the
> return stack and then "returning" to it is no more efficient in *any*
> way. BTW, that is basically how my machine works actually. The JUMP
> instruction has a 4 bit field which is appended to a literal that is
> constructed on the return stack with literal instructions. The JUMP
> instruction then pops this address from the return stack and adds it
> to the PC (relative addressing). I could use a return instruction,
> but that is an 8 bit instruction without the 4 bit literal field and
> would require more literal instructions half the time.
Sure, and on the Novix return is a 1-bit instruction that goes in
parallel with other instructions. That's costly too but in a completely
different way. I'd like to think there might be some approach that's
very different that works well, but likely there isn't. I spent hours
examining arithmetic with gray codes, hoping for a way to make it worth
doing, and I just didn't find one.
Incidentally, the genetic code is 6 bits. It's divided into 3 2-bit
sections, and the way the biochemistry goes, ribosomes provide a very
clear match on the middle bits, they make occasional mistakes with the
first two bits, and the third pair is not all that reliable. And the
genetic code is set up as a sort of gray code. Often a mistake in the
third pair doesn't matter. In 8 out of 16 cases it makes no difference
at all. In another 6 out of 16 it only has to tell purines from
pyrimidines. There are only two cases where it has to be perfect -- it
has to tell methionine from isoleucine (because that's the only coding
that methionine has) and it has to tell tryptophane from a stop signal
(because that's the only coding that tryptophane has).
So it must be that at some time the genetic code was not fixed but
alternate versions were under consideration, and this one won out as
being reasonably efficient. Note that while ribosomes have various
proteins firming up the scaffolding, at core they are made of RNA and
presumably when the genetic code was first developed living things made
all their enzymes out of RNA, and didn't need a genetic code.
