Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Politics : Formerly About Advanced Micro Devices -- Ignore unavailable to you. Want to Upgrade?

To: d[-_-]b who wrote (110702)	5/12/2000 8:02:00 PM
From: Gopher Broke	Read Replies (1) \| Respond to of 1574681

TheRegister has an article on an X-box competitor. Nvidia selected for Linux based X-Box rival Little-known Indrema was formed earlier this year, and is apparently hard at work on its L600 Entertainment System, a Linux-based games console-cum-Net access device-cum-MP3 player. It's based on a 600MHz CPU of unknown provenance For price/performance and portability reasons you might use an IA32 processor to help games developers porting over from x-box?

To: d[-_-]b who wrote (110702)	5/12/2000 10:32:00 PM
From: pgerassi	Respond to of 1574681

Dear Eric and Gopher: Most people writing this kind of code forget that at the time the base word size of a CPU was almost always greater or equal to the size of a char (byte) pointer. The only exceptions were the 8 bit CPUs and many 16 bit CPUs like i8080, Z80, 6800, 6502, 8086 (when using a model larger than compact model), i80186, and i80286 where the pointer was larger than base int. In the 8 bit CPUs, integer was defined as a 16 bit signed word equaling the char pointers 16 bits. In the x86 world before the 80386 (386), an integer was 16 bits but a far char pointer was 32 bits. These were the only processors that had this problem. Of course, when the 386 came out, the base integer was 32 bits and since very few people ever used a far char pointer ever again, it could hold a 32 bit char pointer. Thus using a base integer (int) to store a pointer (anything *) was common practice and does produce working, usable code. It was only someone who thought that the ideal model for integer size modifiers would be 8 bit (char), 16 bit (int), 32 bit (long) where you would get into trouble and only for Large and Huge programming models (Intelspeak). I have always believed if we were to replace the traditional base integer (int) is the base ALU data word (integer) size of the CPU in question, it would be by the model having 8 bit as char (or short short int), 16 bit as short (int), 32 bit as int, 64 bit as long (int), and 128 bit as long long (int). (I do not know what apellations to be used for 256 bits and higher (super?)). The same could be done for floats, 8 bit as short short (char) float (ever needed?), 16 bit as short float, 32 bit as float, 64 bit as double, and 128 as long double (holds x87's temporary real 80 bits). Every 16 bit (and greater) general purpose CPU designed recently (includes most DSPs), will not screw up the traditional work around for versatile pointer arithmetic. It just that most C++ based compilers generate a lot of warnings for the old usage (can be "cast"ed away now for the most part) but still generate good code. It takes some people a long time to change. Pete