Oh, one more timing thing, you have to use the LCD's native resolution and in some cases a single refresh rate. This is normally done by the scan converter in the rear of the desktop display.
PS: What I'm getting at here is that it shouldn't be all that hard to interface a prop directly to this system. Fully digital! [noparse]:)[/noparse]
MOVdB Source(Long to de Combine from),index((0-3)2),Destination(Zero-extended byte)
I now at I can to do it in a few program steps but it is waste of COG RUN memory
Ps. Maybe even increment index after execute and in MOVB increment Destination, in MOVdB increment Source after index wrap over
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stuipid question there is atleast one inteligent awnser If you dont ask you wont know
I mentioned to ad INCrement and DECrement instructions.
To that I have more ideas that them can increment separate BYTEs, WORDs and LONGs.
Examples..
INC destination,BYTE (0-3) > with roll over no action on next byte. Only update wz and wc flags
INC destination,WORD (0-1) > with roll over no action on next word. Only update wz and wc flags
INC destination,LONG > with roll over only update wz and wc flags
Same for DEC instruction
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer If you don't ask you wont know If your gonna construct something, make it·as simple as·possible yet as versatile as posible
Question: can anybody who's been following this thread for a while give a general overview? Normally I read from the begining of a thread, but some 660 posts is more of an essay than a quick dialog...
Essay? No, essays have a beginning, a middle, and an end. This is more like free association. Just be patient. I'm sure Chip will provide some kind of summary soon enough, once things crystalize. Until then, just fasten your seatbelt and enjoy the ride!
I've updated the wiki page that has collected info from this thread and other threads about the Propeller 2. Tonight I added a page with the various new instructions mentioned (that seemed to still be "in").
I have sumarised Yours and My thinks on Instructions WR/RDLONGS and TRLONGS and I marked that we missed out one posiblity on them.
( Chip You said it is fine to have that flags in TRLONGS for memory fill )
In TRLONGS count,increment flags > we have mised one more flag INC/DECWR/RDLONGS addresses on same Indirect register. With that Flag it is Posible to have simple POP/PUSH instructions for Spin and Al virtual CPU emulators.
That instruction was on one of my proposos. Litle edited in this version ········Long to modify.· xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx BITsSET Destination,10,5,10110 <Position,xBits,Bits
Long After·modify······ xxxxxxxxxxxxxxxxxxxxxx10110xxxxx
Exaple POP/PUSH Instructions (With set INC/DECWR/RDLONGS flag POP and othervise PUSH
( I am sure that pople have more ideas and Uses it is only one that I present )
It is one more posiblity that is posible with that flag
I have that discussion on another thread.
Hi Baggers.
YES and NO.
My proposo to SERIN/OUT is so fast and Chips proposo to VIDEO extensions that You can have one COG to VIDEO and RAM controler att same time.
Proposed Instructions that Auto increment (Maybe even DECREMENT) READ and WRITE to HUB is perfect for that type of work.
It is only programers programing skill that limits possibility.
Ps. With 32 Bits mode on SERIN/OUT < You can construct RAM controler with Second PropII elserelatively simple FPGA that have upp to 32 Bits Address and 32 Bits wide data bus. Else 4-8 High Bits That have comand to RAM controler and 28-24 Bits Address.
[noparse][[/noparse]/code]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Hi Sapieha,
Sounds great [noparse];)[/noparse] And I'm sure whatever Chip ends up doing with the Prop II we'll ALL be amazed and in awe of what it can do [noparse]:)[/noparse] I know I will be, and I look forward to having a play when they're done [noparse]:)[/noparse]
My last idea was not meant backwards compatibility BUT to efficiency Stack oriented interpreters. Type ( Spin, C and any other that work in Stack principle mode ).
"" Al virtual CPU emulators. "" is only side efect on that efficiency. That its work principle has also·Intensive Stack USE.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
I have one question abaut WR/RDLONG and WR/RDWORD.
Have You in tehem one free bit to have one specjal flag in them. (flag ALIGNED/NOTALIGNED).
For explanation Ask.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
I think instead of being code compatible i think a kit should be developed to make the new prop ii with the prop one boards. I dont know the specs of the new prop ii but it would be a cut down version of the prop ii but it depends on cost i know.
but looking into something like this should be done
This has been looked into and discussed in some of the long threads. You'd have to use the Prop II as is and perhaps build a module that doesn't use all the I/O pins ... like the Spin Stamp. It would be expensive because you'd have to use a full Prop II and just not connect to some of the I/O pins. It's way too expensive and too time consuming an effort to have a 2nd chip design and you can't just take a large chip and put it in a small package. Frankly, I don't think you can fit a Prop II chip on a module like the PropStick with a 40 pin DIP form factor and certainly not in a 24 pin DIP form factor. It's likely that there will be a breadboardable module, but in a wider package. All of this is my unsupported personal opinion, but I do listen to what other people say who might know more facts than I do and I know how to take incomplete facts and come up with a conclusion.
Is it silly to use 3-4 pins·devoted to a high speed SPI Prop to Prop interface on the 44 pin packages?. Possibly change the programming of the chip, since serial is nearly extinct on most computers·to an SPI or some version of a lite USB that can also be used for Chip to Chip comms.
If your making a break from Prop 1, why does the Prop Plug need to be the same too?
Any implementation of USB or, say, ModBus would be done in software as a protocol on top of the serial bit shifter. How fancy the hardware support for bit shifting is is still up for discussion I believe.
It was too much to go back and re-read the whole post, so here is a suggestion for the PropII .....
(I realise the pipe in the PropII is more complex as Chip has said that each instruction will be effectively single cycle, so this may not work, but I guess there is no harm in stating it anyway).
In the PropI the pipeline is flushed if a jump is not taken. The only cases I can think of are TJNZ, TJZ and DJNZ. Using the IdSDeR cycles...
If the PC (program counter) and the Destination cycles·were enhanced then it may be possible to know just prior to fetching the next I whether the jump will be taken or not.
The PC would have a PC_A and a PC_B register. There must be some form of this for the writeback (R) cycle in JMPRET.
PC_A provides the address to fetch the next I(n) instruction
In the d(n) cycle, instruction decodes and increments PC_A (n+1). It is now known if a jump MAY be taken.
In S(n) cycle, S is also latched by PC_B ready for·a posible jump
In D(n) cycle, D is also decoded and bits 1..31 are tested for ALL ZERO.
If it is a possible jump with TJNZ then if bits 1..31 all zero and bit 0 is zero, no jump will be taken (sets PC_A active, else PC_B is active)
If it is a possible jump with TJZ· then if bits 1..31 all zero and bit 0 is zero, jump will be taken (sets PC_B active, else PC_A is active)
If it is a possible jump with DJNZ then if bits 1..31 all zero and bit 0 is one, jump will be taken (sets PC_B active, else PC_A is active)
If is is a JMP/JMPRET/RET/CALL (with conditions met) then jump will be taken (sets PC_B active and PC_A stores the return address is required)
In e(n) cycle, I(n+1) is fetched using either PC_A or PC_B depending on which was set active in the previous cycle. This will be the correct instruction and so no flush will be required.
In R(n) cycle, if PC_B was active then PC_B will be transferred to PC_A, and if it required writeback (JMPRET, CALL) PC_B is also written to D(n).
If D were fetched before S, the jump could be determined 1 clock earlier.
I seem to recall Chip saying that there would be "free" instructions following the jump that could be executed either way. At least this may minimise them·using something like this concept.
I haven't tried to make sense of what you've said there but since the PropII is having quad ported registers now my guess is that Source and Destination will be simultaneously fetched. Something like:
This column shows the four overlapping accesses.
|
v
#1 ISeR
D
#2 ISeR
D
#3 ISeR
D
#4 ISeR
D
I = Instruction fetch
S = Source register fetch
D = Destination register fetch
e = Execution settle time
R = Result write back
A lot depends on how Chip has pipelined the PropII and that has not been stated. That is why I posted a suggestion (which Chip has probably thought of anyway - but just in case it is useful).
Mike Green said...
This has been looked into and discussed in some of the long threads. You'd have to use the Prop II as is and perhaps build a module that doesn't use all the I/O pins ... like the Spin Stamp. It would be expensive because you'd have to use a full Prop II and just not connect to some of the I/O pins. It's way too expensive and too time consuming an effort to have a 2nd chip design and you can't just take a large chip and put it in a small package. Frankly, I don't think you can fit a Prop II chip on a module like the PropStick with a 40 pin DIP form factor and certainly not in a 24 pin DIP form factor. It's likely that there will be a breadboardable module, but in a wider package. All of this is my unsupported personal opinion, but I do listen to what other people say who might know more facts than I do and I know how to take incomplete facts and come up with a conclusion.
You can take a large chip and put it in a small package, XMOS is doing it with the XS1-4G. The original chip is a BGA512 and they are putting it in a BGA144. The only difference will be less I/Os per core. The BGA512 device has 64 I/Os per core, which is excessive for most applications. Parallax could do the same.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Leon,
I suspect the BGA144 version is a different chip than that used in the BGA512 version. The cost of manufacturing a chip depends heavily on the chip area and the I/O circuitry is usually the greatest area per function since the output transistors and protective diodes have to be fairly large. To leave that many I/O pins unconnected, but occupying chip area, would result in the two versions having approximately the same cost, but very different functionality. In addition, the BGA144 package can't hold as physically large a chip as the BGA512 package.
What they've probably done is to use the same basic core design and stripped out some of the I/O pins resulting in two separate chip designs differing only in the number of I/O pins.
Parallax has already done that with the Prop I. The original design was based on 64 I/O pins, but they designed in only 32 of them. They've since come up with a separate 64 I/O pin design that's held up because of problems with the chip design software.
I just checked and the BGA144 and BGA512 chips have the same silicon inside, they bond out the connections from only two of the cores in the case of the BGA144. All four cores are functional. One of their people told me as much when he phoned me a couple of days ago about some samples I want. I told him I needed four cores in both devices for my applications. The BGA144 is in an 11x11 mm package and the BGA512 is 20x20 mm.
Why not package the PropII in the same chip package as the PropI?
Create a method of interconnecting two (or more chips), making them right/left depending on code.
Wouldn't speed and memory increases work in the same package? I/O would be depend on how
many interconnected chips were present (just as it does now) except that an intercommunication
system would be built in.
Having just started coding for the Prop, I've discovered something that I find very disconcerting - A mixture of both Big Endian and Little Endian. [noparse]:([/noparse] I've never quite understood why anyone would design for LE. It's like someone's playing a joke for no good reason at all.
The Propeller is little endian. If you look at the physical construction of mathmatic operations on individually addressed multi byte variables it is little endian that makes sense and big endian is a big pain. The only reason why we view big endian as "correct" is the fact our language is read left to right, but from an engineer's perspective it has (practically) no merit.
Comments
PS: What I'm getting at here is that it shouldn't be all that hard to interface a prop directly to this system. Fully digital! [noparse]:)[/noparse]
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
I have one question.
You have instructions MOVD, MOVI,MOVS.
But not instructions to Combine and de Combine COG BYTEs in longs.
It is maybe posible have that instructions?
Example....
MOVB Destination(Long to Combine in),index((0-3)2),byte(YYYYYYYY)
···· 3··············· 2············· 1············ 0
xxxxxxxx YYYYYYYY xxxxxxxx xxxxxxxx
MOVdB Source(Long to de Combine from),index((0-3)2),Destination(Zero-extended byte)
I now at I can to do it in a few program steps but it is waste of COG RUN memory
Ps. Maybe even increment index after execute and in MOVB increment Destination, in MOVdB increment Source after index wrap over
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stuipid question there is atleast one inteligent awnser
If you dont ask you wont know
Sapieha
Post Edited (Sapieha) : 9/14/2008 8:40:25 AM GMT
Hey Chip,·any chance of a Prop 1.5 with 16 of the current cogs (and maybe 64kB RAM and 32 I/O)?
How about this: Dual core Prop1... Two props in one package. Maybe the "B" ports can be internally connected for a high speed bus between cores?
I mentioned to ad INCrement and DECrement instructions.
To that I have more ideas that them can increment separate BYTEs, WORDs and LONGs.
Examples..
INC destination,BYTE (0-3) > with roll over no action on next byte. Only update wz and wc flags
INC destination,WORD (0-1) > with roll over no action on next word. Only update wz and wc flags
INC destination,LONG > with roll over only update wz and wc flags
Same for DEC instruction
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer
If you don't ask you wont know
If your gonna construct something, make it·as simple as·possible yet as versatile as posible
Sapieha
Essay? No, essays have a beginning, a middle, and an end. This is more like free association. Just be patient. I'm sure Chip will provide some kind of summary soon enough, once things crystalize. Until then, just fasten your seatbelt and enjoy the ride!
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
Here's the direct links:
Wiki Propeller·2 Page
New Propeller 2 Instructions Page
I'm still working on them, and welcome any feedback from folks here (especially Chip or Paul or Beau).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
[noparse][[/noparse]code]
I have sumarised Yours and My thinks on Instructions WR/RDLONGS and TRLONGS and I marked that we missed out one posiblity on them.
( Chip You said it is fine to have that flags in TRLONGS for memory fill )
In TRLONGS count,increment flags > we have mised one more flag INC/DEC WR/RDLONGS addresses on same Indirect register. With that Flag it is Posible to have simple POP/PUSH instructions for Spin and Al virtual CPU emulators.
That instruction was on one of my proposos. Litle edited in this version
········Long to modify.· xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
BITsSET Destination,10,5,10110 <Position,xBits,Bits
Long After·modify······ xxxxxxxxxxxxxxxxxxxxxx10110xxxxx
Exaple
POP/PUSH Instructions (With set INC/DEC WR/RDLONGS flag POP and othervise PUSH
( I am sure that pople have more ideas and Uses it is only one that I present )
··· BITsSET TRLONGS pointer,xx,x,10110· < Memory pointer,Position,xBits,Bits> (count,incremect flags and INC/DEC WR/RDLONGS flag)
·· TRLONGS count,increment HUB/COG flags,INC/DEC WR/RDLONGS flag
·· WR/RDLONGS (RegIndexPair),cog_address,hub_address >for nested posiblites
It is one more posiblity that is posible with that flag
I have that discussion on another thread.
Hi Baggers.
YES and NO.
My proposo to SERIN/OUT is so fast and Chips proposo to VIDEO extensions that You can have one COG to VIDEO and RAM controler att same time.
Proposed Instructions that Auto increment (Maybe even DECREMENT) READ and WRITE to HUB is perfect for that type of work.
It is only programers programing skill that limits possibility.
Ps. With 32 Bits mode on SERIN/OUT < You can construct RAM controler with Second PropII else relatively simple FPGA that have upp to 32 Bits Address and 32 Bits wide data bus. Else 4-8 High Bits That have comand to RAM controler and 28-24 Bits Address.
[noparse][[/noparse]/code]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Post Edited (Sapieha) : 9/25/2008 9:19:56 PM GMT
Backward compatibility does not belong on the device. Let the compiler, converter, or code developer manage backward compatibility externally.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Dennis B. Page, Page Radio Company
Sounds great [noparse];)[/noparse] And I'm sure whatever Chip ends up doing with the Prop II we'll ALL be amazed and in awe of what it can do [noparse]:)[/noparse] I know I will be, and I look forward to having a play when they're done [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
My last idea was not meant backwards compatibility BUT to efficiency Stack oriented interpreters. Type ( Spin, C and any other that work in Stack principle mode ).
"" Al virtual CPU emulators. "" is only side efect on that efficiency. That its work principle has also·Intensive Stack USE.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Post Edited (Sapieha) : 9/25/2008 9:24:37 PM GMT
I have one question abaut WR/RDLONG and WR/RDWORD.
Have You in tehem one free bit to have one specjal flag in them. (flag ALIGNED/NOTALIGNED).
For explanation Ask.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
I think instead of being code compatible i think a kit should be developed to make the new prop ii with the prop one boards. I dont know the specs of the new prop ii but it would be a cut down version of the prop ii but it depends on cost i know.
but looking into something like this should be done
Badger
If your making a break from Prop 1, why does the Prop Plug need to be the same too?
(I realise the pipe in the PropII is more complex as Chip has said that each instruction will be effectively single cycle, so this may not work, but I guess there is no harm in stating it anyway).
In the PropI the pipeline is flushed if a jump is not taken. The only cases I can think of are TJNZ, TJZ and DJNZ. Using the IdSDeR cycles...
If the PC (program counter) and the Destination cycles·were enhanced then it may be possible to know just prior to fetching the next I whether the jump will be taken or not.
The PC would have a PC_A and a PC_B register. There must be some form of this for the writeback (R) cycle in JMPRET.
PC_A provides the address to fetch the next I(n) instruction
In the d(n) cycle, instruction decodes and increments PC_A (n+1). It is now known if a jump MAY be taken.
In S(n) cycle, S is also latched by PC_B ready for·a posible jump
In D(n) cycle, D is also decoded and bits 1..31 are tested for ALL ZERO.
If it is a possible jump with TJNZ then if bits 1..31 all zero and bit 0 is zero, no jump will be taken (sets PC_A active, else PC_B is active)
If it is a possible jump with TJZ· then if bits 1..31 all zero and bit 0 is zero, jump will be taken (sets PC_B active, else PC_A is active)
If it is a possible jump with DJNZ then if bits 1..31 all zero and bit 0 is one, jump will be taken (sets PC_B active, else PC_A is active)
If is is a JMP/JMPRET/RET/CALL (with conditions met) then jump will be taken (sets PC_B active and PC_A stores the return address is required)
In e(n) cycle, I(n+1) is fetched using either PC_A or PC_B depending on which was set active in the previous cycle. This will be the correct instruction and so no flush will be required.
In R(n) cycle, if PC_B was active then PC_B will be transferred to PC_A, and if it required writeback (JMPRET, CALL) PC_B is also written to D(n).
If D were fetched before S, the jump could be determined 1 clock earlier.
I seem to recall Chip saying that there would be "free" instructions following the jump that could be executed either way. At least this may minimise them·using something like this concept.
·
This column shows the four overlapping accesses. | v #1 ISeR D #2 ISeR D #3 ISeR D #4 ISeR D I = Instruction fetch S = Source register fetch D = Destination register fetch e = Execution settle time R = Result write backYou can take a large chip and put it in a small package, XMOS is doing it with the XS1-4G. The original chip is a BGA512 and they are putting it in a BGA144. The only difference will be less I/Os per core. The BGA512 device has 64 I/Os per core, which is excessive for most applications. Parallax could do the same.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
I suspect the BGA144 version is a different chip than that used in the BGA512 version. The cost of manufacturing a chip depends heavily on the chip area and the I/O circuitry is usually the greatest area per function since the output transistors and protective diodes have to be fairly large. To leave that many I/O pins unconnected, but occupying chip area, would result in the two versions having approximately the same cost, but very different functionality. In addition, the BGA144 package can't hold as physically large a chip as the BGA512 package.
What they've probably done is to use the same basic core design and stripped out some of the I/O pins resulting in two separate chip designs differing only in the number of I/O pins.
Parallax has already done that with the Prop I. The original design was based on 64 I/O pins, but they designed in only 32 of them. They've since come up with a separate 64 I/O pin design that's held up because of problems with the chip design software.
http://forums.parallaxinc.com/products.xmos.com/system/files/XS1-G4-PB-080723.pdf
They must be using the very latest technology, to get them that small.
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
Post Edited (Leon) : 10/11/2008 4:56:57 PM GMT
Create a method of interconnecting two (or more chips), making them right/left depending on code.
Wouldn't speed and memory increases work in the same package? I/O would be depend on how
many interconnected chips were present (just as it does now) except that an intercommunication
system would be built in.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with a Propeller Protoboard?
Check out: Introduction to the Proboard & Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card connected? - PropDOS
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 10/27/2008 4:08:43 PM GMT