1. Bytes vs Bits?
>> [Bytes vs Bits?]
>> Martin, I'm not sure what [any of us] mean by a btye, but here's my
>> definition:
>Call me old fashioned, but I think a byte is 8 bits. I know! I'm a stick
in
>the mud! But I think it might be easier all round.
LOL too bad 11 isn't divisible by 4, or it might work ;)
...even at that point, we'd be at nibbles and not bytes...
>> 12099960044 - this is not a byte, this is a complete instruction
>> 4 - this *is* a byte, a part of the instruction
>Looks like a digit to me 
Would a rose by any other name smell as sweet?
>> Every full instruction is 11 bytes long.
>Seems like a lot to me 
I think the problem here is, you're thinking in normal computing terms
for
"byte", and I'm simply redefining it to suit my purposes. (splitting
hairs?
yeah probably).
Every instruction is NOT this long:
101100101 01001011 10100001 10010110 01011010 101100101 01001011 10100001
10010110
01011010 00010001
:)
>> Here's the breakdown:
>> opcode: 1 byte (0-9)
>only 10 opcodes
This is addressed in the new compiler I sent to the list.
>> 1st operand mode: 1 byte (0-2)
>> 2nd operand mode: 1 byte (0-2)
>> 1st operand: 4 bytes (0000-9999)
>> 2nd operand: 4 bytes (0000-9999)
>only 10000 possible values
Sofar, we only need 10000 possible values, because the core size limit is
10000 :) The same goes for the addressing modes: right now there's only
3
modes, but there could be as many as 10.
The real problem (which you identified) is in the opcode, because now we
want
to extend it beyond 10 opcodes, but there's no room.
>But what if we did this:
>opcode = 4 bits - This allows space for 16 opcodes, not the 10 you have
now
>1st op mode = 2 bits - This allows for 4 modes, but we only need 3
>2nd op mode = 2 bits - This allows for 4 modes, but we only need 3
whoa! you're thinking in 1's and 0's!
it's this literal computer thing that's not working for ya my friend :)
terminology aside, if you look at Rod's code and my code, you'll see
we don't even *use* literal bits and bytes (in the normal sense). what
we're really dealing with is sequences and atoms.
>And we could probably find low-level bit operations that would make
>the massaging process really fast.
although it's not the way we're coding it right now, this low-level bit
thang might be cool :) I'm not familiar with the bit-level routines,
but I'll check em out and try some things...
of course it's all going to be up to Rod to implement this in his
simulator.
>Anyway - I'll write up a few routines to handle this and see what you
think.
can't wait to see em
----->Buddy
budmeister1 at juno.com
2. Re: Bytes vs Bits?
Hi
Here are a couple of conversion funtions, to demonstrate what the result
would be like if we were to translate the corescripts into sequences of 5
bytes per instruction, instead of the 11 digit number per instruction that
is being used now.
One function, "byteit(instruction)" takes the opcode, mode1, mode2, arg1,
and arg2 and makes a string of 5 bytes from them. I visualize these being
poked to the corememory in 5 successivel locations.
The second function "spititout(instruction)" takes a sequence of 5 bytes
from the corememory and converts them into the opcode, mode1, mode2, arg1,
arg2 format that Rod's interpreter uses.
Still to come is the bit-level arithmetic. I don't know much about it. But I
think that at least the opcode and modes should be extractable without all
that calculation. Also, I haven't looked at the detail of integrating this
with Rod's interpreter - maybe it won't work.
And as I write, new compilers and interpreters are being written. Will I
ever catch up?
bye
Martin
>>>>>>>>Start of Euphoria Code
-- These two functions convert the output of Buddy's Corescript_to_atom
-- from the bignumber that is now being used into the sequence of
-- "bytes" that I'm recommending.
-- As I'm reading it, corescript_to_atom returns a sequence of instructions
-- These routines convert those instructions
-- Usage:
-- Where - data = corescript_2_atom(data, 0)
-- sequence newdata
-- newdata={}
-- for i = 1 to length(data)
-- newdata &= byteit(data[i])
-- end for
--
sequence instruction
function byteit(sequence instruction)
atom byte1, byte2, byte3, byte4, byte5
byte1=instruction[1]*16+instruction[2]*4+instruction[3]
byte2=floor(instruction[4]/256)
byte3=remainder(instruction[4],256)
byte4=floor(instruction[5]/256)
byte5=remainder(instruction[5],256)
return ({byte1, byte2, byte3, byte4, byte5})
end function
function spititout(sequence instruction)
atom opcode, mode1, mode2, arg1, arg2
opcode=floor (instruction[1]/16)
mode1=floor(remainder(instruction[1],16)/4)
mode2=floor(remainder((remainder(instruction[1],16)),4))
arg1=instruction[2]*256 + instruction[3]
arg2=instruction[4]*256 + instruction[5]
return({opcode, mode1, mode2, arg1, arg2})
end function
-- These are just tests of the functions
instruction = {4,1,1,1200,300}
?(instruction)
?(byteit(instruction))
?(spititout(byteit(instruction)))
?({})
instruction = {4,2,1,300,300}
?(instruction)
?(byteit(instruction))
?(spititout(byteit(instruction)))
?({})
instruction = {4,3,3,300,300}
?(instruction)
?(byteit(instruction))
?(spititout(byteit(instruction)))
?({})
instruction = {5,1,1,300,300}
?(instruction)
?(byteit(instruction))
?(spititout(byteit(instruction)))
>>>>>>>>End of Euphoria Code
