Started by PabloMack, May 22, 2019, 07:29:52 pm
Quote from: Oshyan on June 09, 2019, 01:43:03 pmI sort of wondered if you might be able to seek funding from them given the stated goals of the EPI itself (separate from the current choice of approach).- Oshyan
Quote from: Oshyan on June 09, 2019, 02:17:32 pmOhh, somehow I thought you were in Europe. Ah well - Oshyan
Quote from: PabloMack on June 09, 2019, 02:23:32 pmQuote from: Oshyan on June 09, 2019, 02:17:32 pmOhh, somehow I thought you were in Europe. Ah well - OshyanIt's probably because I talk so much about Unicode. When I say the word to most Americans, I just get a blank stare. "Uni-what?". Americans in particular are quite happy with ASCII. They don't understand why everybody else doesn't just dump their character sets and do everything the way they do it. After all, the 'A' in ASCII stands for American!
Quote from: PabloMack on June 03, 2019, 03:06:34 pmI was just looking at the ARM64 manual and I'd hate to have to write a code generator for that monster. I really miss Motorola's manuals because they were so much better than anyone else's. What I want for the average programmer is something that they can easily understand. I think it is a tragedy when CPUs are so complicated that it puts the control of the whole market into the hands of a few billion-dollar companies.
Quote from: Matt on June 09, 2019, 09:11:23 pmThere will always be enough smart people to write compilers for difficult-to-understand CPUs (not just in multi-billion dollar companies, but also independents) so that the rest of us don't have to understand them, but they are not "average programmers" IMO.
Quote from: PabloMack on June 10, 2019, 02:55:40 pmComputer complexity comes in at least two varieties. One is easy to manufacture but difficult to understand (RISC). The other is easy to understand but difficult to manufacture (CISC) . During the last 20 years, all new designs have been RISC. But there are basic principles that say that "smarter is better". CISC processors have smarter instructions so shouldn't they run faster?
QuoteI have another story about when I was working for a large corporation. I was part of a department called "Advanced Process Control". We used DEC computers to automate data collection while they were using an IBM mainframe (AS/400). The IS department hated us because we could do it better than they could. As the saying went "Nobody got fired for choosing IBM." One time my boss (a DEC proponent) attended a meeting between IS people and IBM. He laughed at our IS management because they would say "This is really complicated and we can't understand it. It must be good!"
Quote"Movie-makers don't care about how complex CG software is because the artists will deal with that to make life simpler for us. That is their job. There will always be artists to fill that need."
Quote from: Asterlil on June 10, 2019, 06:19:00 pmSince I retired from programming (sort of)(you can check out any time you want, but you can never leave), ...
Quote from: PabloMack on June 10, 2019, 09:35:23 pmQuote from: Asterlil on June 10, 2019, 06:19:00 pmSince I retired from programming (sort of)(you can check out any time you want, but you can never leave), ...When you were programming, what languages did you use before the noob ones came out? Java Script is really part of the HTML web-based group of languages so its strength is portability. It and others like it (Python comes to mind) are like an RV where you take everything with you as you go. But your programs will be plodding along like tortoises. Languages like C, C++ and ϕPPL are more like Ferrari's or Corvettes that make good use of the machine's performance. They are more like Cheetahs or Falcons.
Quote from: Matt on June 10, 2019, 05:34:45 pmFor the "ease of use" goal, from my layman's perspective it appears that this might result in a shift of responsibilities between the CPU and the compiler. Within the definition of "compiler" I would also include a code generator whose input is some very low-level language that's more in tune with the needs of the CPU but whose instructions might not map 1:1 to the CPU itself. Outsourcing some of the implementation from the hardware to the first software layer (as long as it's compiled) doesn't seem unreasonable to me. To put it another way, you could define a virtual CPU that is easy to program. It may be fully implemented in hardware, or there might be a software layer. The boundary between hardware and software would be decided by the implementation, not the specification.