Is Pelles C a dead fish?

[Stefan Pendl]

In almost all modern OS's, especially in WinNT, this concept is expanded and called Hardware Abstraction Layer (commonly known as HAL). In this case not only the access to the hardware, but even functionalities are abstracted. Think of it like a virtual hardware. In this way lower level routines can be created to access hw resources, or emulate them on platforms that miss a specific function.
To move an OS from one hw platform to another you have to recompile the C code, write some HAL low level code (even for this ASM is limited to hw wrappers), then link and test. 

This is why LINUX can be moved from one HW to another in a couple of days....

Android seems to have taken this approach much further, since it runs more or less as a VM.
The future is about mobile devices, but stationary ones will still be needed for high performance use.

If there would be an abstraction layer that offers a common interface to the software and is working on every operating system, things would be much easier.

A common architecture like below would be nice.

• Hardware
• HAL
• Operating system
• OSAL
• Software

[frankie]

Stefan,
indeed there is: POSIX 
On POSIX is based X-Window that leads to GTK, etc.
But commercial SW don't like to conformate too much 
Anyway your list make me remember of networking ISO-OSI standard (7 levels from phisycal to application), at the end it won (even if not all levels are always present) to allow different products to work together. Maybe in far far future this will happen if something new will come out to induce producers to talk same language.... 

P.S. some technologies like MS COM (Component Object Model) are already available to different systems as DCOM (Distribuited Component Object Model).
DCOM is still MS patent, but available on LINUX, SOLARIS, etc.

[CommonTater]

Yes Tater, but writing in ASM has a couple of drawbacks:

Hi Frankie,
Thank you for such a nice explaination of hardware abstraction. 

I've known some of this for a while and I agree that ASM has this particular drawback of not being portable but then very little compiled code is portable... mostly what people are "porting" is source code.

However; ASM also has the advantage of producing high performance code, as is needed for many kernel and driver level functions.  So the tradeoff is that hardware manufacturers most often provide the core driver for a given device (chip, board, disk etc.) and these are in turn interfaced to the OS through an abstraction layer as you indicated. 

It ain't perfect... but it obviously does work.

[CommonTater]

Hi Stephan...
 

Android seems to have taken this approach much further, since it runs more or less as a VM.
The future is about mobile devices, but stationary ones will still be needed for high performance use.

Java was supposed to be one of thosie "universal API" interfaces.  The idea being that a hardware producer could provide an abstraction layer that was common to all systems, then programmers could write code that worked on all systems.  The only real problem was that Java was basically a giant and cumbersome interpreter... with all the problems that implies.

.Net was another attempt at this and only now is MS realizing the degree of bloat it imposed on user's systems. 

The future may be about mobile devices --I shudder to think of all the crap people will be carrying with them-- but, as you point out, most of the really good stuff will still be happening on workstations. 

[frankie]

However; ASM also has the advantage of producing high performance code, as is needed for many kernel and driver level functions.

Hi Tater 
That's not really true, some really optimized compilers are known to be 1:1 with assembler (i.e. Intel C++), and even better sometimes, but anyway you have to consider that a driver code is the very core part of hardware access so it don't use any library or other bloated code. Normally the use of port I/O instructions is enough, so translation from C to assembler is straightforward.
Moreover as already said most of the code is always in C and only the real low level is in assembler.

About fast code just an example: if you look at the video codec free libraries you will find that many of the computational core software is also available in assembler, but the precompiled libraries always use the C coded one (because is faster to compile & debug and because the assembly sample is tailored for a processor: penthium, PII, PIII etc). Anyway anybody can play a full-HD movie with no difference to notice..... 

[CommonTater]

Hi Tater 
That's not really true, some really optimized compilers are known to be 1:1 with assembler (i.e. Intel C++), and even better sometimes, but anyway you have to consider that a driver code is the very core part of hardware access so it don't use any library or other bloated code. Normally the use of port I/O instructions is enough, so translation from C to assembler is straightforward.
Moreover as already said most of the code is always in C and only the real low level is in assembler.

This I knew.  ASM is used only in very specialized cases these days.  Still the advantages and disadvantages are about as we've said.

As an application programmer, I very seldom have any need to dip into ASM and only rarely need to mess with anything but Windows API, so I'm always glad of the reminders for what does what best 

[jj2007]

some really optimized compilers are known to be 1:1 with assembler (i.e. Intel C++), and even better sometimes

That is probably true. It would be nice if Microsoft used these compilers for the C Runtime Library - here are some randomly picked comparisons between assembler and CRT functions.

Intel(R) Celeron(R) M CPU        420  @ 1.60GHz (MMX, SSE, SSE2, SSE3)

Comparing two strings which differ at position 500,000:
189     ms for StringsDiffer (asm),     1000 differences found
970     ms for strcmp (CRT),            1000 differences found

Comparing two strings, case-insensitive, ca. 955 kBytes:
653     ms for StringsDiffer,   0 differences found
2097    ms for CRT strcmpi,     0 differences found

Get the overall length of the first string:
194     ms for Asm Len,         977412 bytes found
616     ms for CRT strlen,      977412 bytes found

EDIT: Added a small change to prevent it from crashing if a binary file was submitted via the commandline.

[CommonTater]

some really optimized compilers are known to be 1:1 with assembler (i.e. Intel C++), and even better sometimes

Interesting ... Was that Pelles CRT or Microsoft's? 

There is this concept called "Premature Optimization" that can be quite the trap if you aren't careful.  This is the case when you spend 6 months developing and debugging something that shaves 10ms off a program's execution time.  Unless the program itself is essentially time critical what you've really done is spend an enormous amout of time on what amounts to a microscopic improvement. 

Using the ASM versions can be a real advantage if you have large arrays of long strings, say, for example, a list of 100,000 1meg buffers from some hyper fast disk array.  But what is the gain if you are comparing a user's name and password in a list of 50 people?  It's over in a heartbeat either way, the user won't even notice the time difference and how much work did you do for that? 

This is not to trash ASM, in fact, I'm guessing that the best performing CRTs are largely ASM... but it does raise the question about the time and effort put forth as opposed to the time and effort saved.  If you're going to save your user 5ms while logging in, forget it, not worth doing... if you're going to do real time logging from a 1gbps hard disk array, well, maybe it's worth it.

[jj2007]

So Tater, if I understand you correctly, you write that Frankie's remark about optimising compilers better than Asm is completely irrelevant because speed doesn't matter?

(on the other hand, why is it that MS Office & Firefox & Adobe's crap are so incredibly slow... )

[CommonTater]

So Tater, if I understand you correctly, you write that Frankie's remark about optimising compilers better than Asm is completely irrelevant because speed doesn't matter?

I did not and would not say that speed doesn't matter and no way do I think the optimizing compilers are pointless. You are saying that I said that.  Please do not put words in my mouth so that you can argue with them ... that won't earn you any friends on this end.

What I said was that in many cases speed is less important than most programmers seem to think it is... Why do you need sub-millisecond functions in a program that spends 99% of it's time waiting for you to click a mouse?  Then on the other hand you absolutely do need them in a program that's processing huge quanties of streaming data...  It's a question of sensible priorities.
 
http://scientopia.org/blogs/goodmath/2011/05/03/the-perils-of-premature-optimization/
http://greybeardedgeek.net/2011/04/08/premature-optimization/

[Bitbeisser]

That Assembler (btw, where is the assembler here) vs. C example is most likely comparing apples and oranges here anyway.

Without seeing the corresponding C source code, I would strongly convinced that the C code is taking at least some precaution of dealing with Unicode strings, while the supposed to be assembler code seems to process single byte character strings only.

Ralf

[jj2007]

I did not and would not say that speed doesn't matter

Thanks for the clarification, Tater

"There is this concept called "Premature Optimization" that can be quite the trap if you aren't careful."

I love that one, Tater. And I promise I'll be careful from now on.

[CommonTater]

Without seeing the corresponding C source code, I would strongly convinced that the C code is taking at least some precaution of dealing with Unicode strings,

... error trapping, localization, character translation...

[jj2007]

Without seeing the corresponding C source code, I would strongly convinced that the C code is taking at least some precaution of dealing with Unicode strings, while the supposed to be assembler code seems to process single byte character strings only.

Ralf,
Why don't you just look under the hood? Here is the innermost loop of MSVCRT strcmpi:

77C183B0        0AC0                 or al, al
77C183B2       74 2E                je short 77C183E2
77C183B4        8A06                 mov al, [esi]
77C183B6        46                   inc esi
77C183B7        8A27                 mov ah, [edi]
77C183B9        47                   inc edi
77C183BA        38C4                 cmp ah, al
77C183BC       74 F2                je short 77C183B0

... and voilà, no check for Unicode.

But if you like true Unicode, let's add a test:
Intel(R) Celeron(R) M CPU        420  @ 1.60GHz (MMX, SSE, SSE2, SSE3)

Find a string in a UTF-16 file, Chinese text:
388     ms for Asm wInstr, match found at pos 12031 (10,000 loops)
636     ms for CRT wcsstr, match found at pos 12031 (10,000 loops)

Find a string in a UTF-16 file, Chinese text, case-insensitive:
389     ms for Asm wInstr, match found at pos 12031 (10,000 loops)
1343    ms for StrStrIW,   match found at pos 12031 (one-thousand loops)

Find a string in a UTF-16 file, short Russian text, case-insensitive:
225     ms for Asm wInstr, match found at pos 562 (100,000 loops)
638     ms for StrStrIW,   match found at pos 562 (ten-thousand loops)

There is apparently no CRT equivalent for the case-insensitive wInstr(), so the Microsoft-recommended option seems to be StrStrIW of ShlWapi. Note that in the timings above, StrStrIW does only 10% of the loops, otherwise you could go for a coffeebreak...

P.S.: Just in case: Yes,.wInstr does use LCMapStringW. Still strongly convinced?
 

[migf1]

I think this thread has been evolved into the definition of "off-topic" :lol:

Anyway, I'll stick to my original stand, unless I'm convinced otherwise by others...

a) Open Source gives much more motivation for more people to actively involve in a project, plus it gives them the chance to embed any improvements (and/or bugs ) right into the original code, with any implied pros and cons compared to external patching

b) A platform that has officially dropped the use of a particular programming language for a long time, in favor of other langs and tools, has a huge negative impact in (not) motivating people to involve in a project that deals with that officially long dropped language. Especially when at least another popular platform is evolving in parallel using that programming language as its point of reference (e.g Gnome/GNU)