Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Monday March 07 2016, @01:05AM   Printer-friendly
from the Where's-Major-Kong-when-you-need-him? dept.

Liliputing reports

Most modern desktop and notebook computers ship with Intel or AMD processors and Windows or OS X software. A few companies are positioning products with ARM-based chips as desktop computers. But the Tavolga Terminal TB-T22BT(русский [1]) is something different.

This all-in-one desktop PC has a MIPS-based processor and runs Debian 8 Linux software.

The computer is made by Russian company T-Platforms, which also offers an SF-BT1 processor module for those that want to build their own hardware.

Both devices use a Baikal-T1 processor which is a 32-bit dual-core MIPS P5600 processor. Like the computers, the chip was designed in Russia, although it's based on work from Imagination Technologies (the company behind the MIPS architecture).

The all-in-one desktop features a 21.5 inch IPS display, support for up to 8GB of DDR3-1600 memory, and up to 64GB of flash storage. It has four USB 2.0 ports, a PS/2 port, Gigabit Ethernet, and a fanless case for silent operation. There's also support for smart cards.

T-Platforms is positioning the TB-T22BT as a device that can either be used as a standalone computer with support for Linux-based apps such as LibreOffice and Firefox, or as a thin client system that you can use to connect to remote machines using remote desktop software.

[1] The translation dropdown menu did not work. Google translation

Previous: Russia Plans to Dump Some American CPUs for Homegrown Technology


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Interesting) by dltaylor on Monday March 07 2016, @07:43AM

    by dltaylor (4693) on Monday March 07 2016, @07:43AM (#314791)

    Personally, having used, and programmed for, just about every CPU core out there, since I can't have an 88K, I think I'd rather have a MIPS.

    8 ins/outs/local/global is just too arbitrary for my taste; pass what you need, preferably in register, and have loads of "local" that the compiler decides need to be saved/restored.

    Back when both the 88K and 32-bit SPARC were current, the 88K at 25 MHz kicked the ass of a 75 MHz SPARC.

    Starting Score:    1  point
    Moderation   +2  
       Interesting=2, Total=2
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 3, Interesting) by TheRaven on Monday March 07 2016, @12:36PM

    by TheRaven (270) on Monday March 07 2016, @12:36PM (#314886) Journal

    Back when both the 88K and 32-bit SPARC were current, the 88K at 25 MHz kicked the ass of a 75 MHz SPARC.

    The SPARC initially had a hugely inefficient software-managed TLB. It was common to spend 50% of total CPU time in the TLB miss handler. This was improved a lot in later versions. I'm not sure how bad the 88K was (also a software-managed TLB, as are most MIPS chips, but nowhere near as bad as the early SPARCs), but I wouldn't be surprised if a lot of the performance difference came from this.

    It's also worth noting that the compiler can use any of the 8 out registers as temporaries (not preserved across calls, but lots of register assignments don't need to be) and any of the 8 in values that are not in use as saved registers. That gives you quite a lot of space - it's pretty rare for register starvation to be a problem on SPARC.

    The S in SPARC stands for scalable, because different implementations are allowed to have different numbers of register windows. This ranges from 2-9 in implementations that I've seen. With small numbers, the fact that the overflow routine has to spill values even if there's nothing really valuable in them can make things a lot worse than if you have a more conventional calling convention, but with a larger number then the elimination of stack spills in the common case can be a fairly big win.

    SPARC is also a lot less likely to suffer from return-oriented programming vulnerabilities. The link register is never spilled to the main stack (it's spilled to the space where you spill register windows if you run out of hardware register windows), so no stack buffer overflow can allow overwriting the return address on SPARC.

    --
    sudo mod me up