TC and memory

[Rich]

Hi Paulo

Microsoft Excel format?

You could if you knew the data format used,
Fprintf is exactly the same as printf except it takes a file pointer as its first argument.

[Rich]

Hi Paulo

You could if you knew the data format used,

Nonsense, you could just save it in a comma separated format, Excel should be able to handle reading that.

[Paulo]

Hi Rich

You could if you knew the data format used

Interestingly Microsoft dumped their own crappy Excel format as of Office7 (I think).
The latest Excel (and Word) actually use xml.
Excel creates files with a .xlsx extension but all it is are zipped xml files.
Try it out, create a simple Excel worksheet then save it, then change the extension to .zip
and have a look at the contents.

Actually Microsoft got into quite hot water over using xml which is an open standard and they tried to
use it as their own.

As regards fprintf, it looks pretty handy, thanks for mentioning it.

[tinypoodle]

BTW, elksemu is included in the Dev86 extension.

[genec]

Office 2007 is Office 12.

[genec]

1) The "real time" part in either C or ASM, haven't quite decided yet.

Am I missing something here?

To quote someone's code who has a notable amount of ASM experience "asm-mode sucks".  Unless you know your ASM is highly optimized, my understanding is that GCC's output will easily do at least as good in far less time.  If you compare C to Java or Perl, sure, there's often a difference in overhead.

[Rich]

HI genec
Someone proficient in assembly might be able to generate faster or smaller code than GCC, but would probably
be hard pressed to do so. To do so, you need to be familiar with the execution time and the number of bytes required
by each instruction the processor supports, in order to select the optimum instructions for the task at hand. If someone
wants to see the assembly code GCC generates, add:

Code: [Select]

-Wa,-alh=YourProgramsName.lst -masm=intelwhen you invoke GCC. The  .lst  file will contain a mix of the C source and assembly language. Then add the -Os or -O2
directive and try following the assembler produced.

[Paulo]

ASM does involve a bit more work to optimize it fully.
As Rich mentioned, this involves looking thru the pages of the Intel datasheets for the processor involved
and checking clock cycles and number of bytes taken by each instruction.

In the "good old days" of the 186, 286 and to some extent the 386, ASM programmers would try and squeeze
every last drop of performance by even saving a clock cycle or two by using:

Code: [Select]

xor eax, eax

Instead of:

Code: [Select]

mov eax, 0

These days, processors are so fast and have features like caching, prefetching and so on that it makes no difference.
(Although that is not to say that optimization is no longer required).

A lot of great optimization tricks can also be learnt from de-compiling and studying the source of computer games from the DOS era.

I know that gcc can produce pretty tight code but I have only used it when I want to mix C and inline ASM.
For purely ASM I use FASM as it has extensive macro capabilities thus making one's life just a bit easier.
By using the macros as includes, it allows the use of highly optimised functions which are easier to "tune" then the equivalent C .h files and built-in functions.
It can also produce executables in PE and ELF formats as well as flat binaries.

I guess at the end of the day, a lot of it also comes down to personal preference and to what is used, gcc, nasm or fasm.

[tinypoodle]

A lot of great optimization tricks can also be learnt from de-compiling and studying the source of computer games from the DOS era.

Why that when there are open source Linux games?

e.g.:
http://www.deater.net/weave/vmwprod/tb1/tb_asm.html

[Paulo]

Hi tinypoodle

Why that when there are open source Linux games?

e.g.:
http://www.deater.net/weave/vmwprod/tb1/tb_asm.html

Nothing wrong with "peeking" at Linux games too, however that specific example is not a great one
as it uses AT&T syntax whereas Intel syntax is not only more widespread but less crazy.
(Sorry but in my opinion, AT&T syntax is just weird).

I mentioned DOS games because:

1) There are more of them, I certainly have lots of older ones from when I had time to play them.

2) The older DOS games are written to do more with less as opposed to the Linux ones which generally rely
on the user having more modern processors.
Also remember that some old DOS games were actually in the COM format which made it easier to understand as no header,
relocation tables and all that other stuff, pretty much the same as a flat binary but starting at 0x100.
The mere fact that they were in COM format, restricted their size to 64KB maxwhich in itself forced the programmer to resort to lots
of optimization techniques to get the whole game under that limit.

3) By de-compiling executables, one also learns about reverse engineering and the use of disassemblers
which although not crucial to being a good programmer, does tend to teach more about the make up of executables, their sections
and the data layout whether it be in COM, MZ, PE or ELF format.

4) The challenge of being able to "see" the source from an executable that might be packed and/or protected.

[curaga]

But does TC make use of BIOS at all after booting?

This is not my area of expertise, but at least the vesa modesetting code calls the BIOS. (Xvesa, Xorg vesa module, or vesa framebuffer). The VGA text console setup likewise.

xor eax, eax

Heh, I remember the first time I saw that in GCC's output and wondered why the heck did it do that. Not exactly a clear way to set it to zero.

[Paulo]

Hi curaga

This is not my area of expertise, but at least the vesa modesetting code calls the BIOS. (Xvesa, Xorg vesa module, or vesa framebuffer). The VGA text console setup likewise.

I'm actually surprised that a modern 32 bit protected mode O.S. like Linux would use BIOS to switch video modes instead of using drivers to interact directly with the VGA registers.
Although having said that I can understand why it's done that way as it's much more work to first query the PCI bus, then find the vendor ID, bus number the card is on, get the subfunctions
then having to see what card/chip set is being used as they all have their quirks, then get the PCI BARs and plug the correct values into the required registers and sometimes it has to be done in a certain order on some cards.

Heh, I remember the first time I saw that in GCC's output and wondered why the heck did it do that. Not exactly a clear way to set it to zero.

Yup, the idiosyncrasies of the x86 architecture, where it's more "economical" to xor a register with itself rather then load it with an immediate constant of zero.
When we get to direct and indirect addressing (in Real Mode) then it becomes a veritable hornets nest as to the use of 'lea' (and others) as it depends not only on the processor
used (386, 486, 586 and up) but also which segment:offset we are using/loading/updating.

[curaga]

I'm actually surprised that a modern 32 bit protected mode O.S. like Linux would use BIOS to switch video modes instead of using drivers to interact directly with the VGA registers.

You have the choice here - in TC we default to the vesa driver (which uses the BIOS), since it's both smaller and works with most cards. But the proper drivers are also available (see the Xorg extensions) for when you need gpu acceleration or non-vesa resolutions.

[genec]

HI genec
Someone proficient in assembly might be able to generate faster or smaller code than GCC, but would probably
be hard pressed to do so.

Agreed (and also my point).  ASM is best for final stages of compilers (like GCC) special items like MBRs and microcode and utilizing interfaces not provided through the language.  An example of the latter I'm familiar with is the implementation of Syslinux's intcall() to call BIOS ISRs (while intcall() should be used in most code)

[genec]

In the "good old days" of the 186, 286 and to some extent the 386, ASM programmers would try and squeeze
every last drop of performance by even saving a clock cycle or two by using:

Code: [Select]

xor eax, eax

Instead of:

Code: [Select]

mov eax, 0

These days, processors are so fast and have features like caching, prefetching and so on that it makes no difference.
(Although that is not to say that optimization is no longer required).

It's still common today, especially in optimized (GCC) or specialized (MBR, microcode) code.  An immediate as above is 6 (66 B8 00 00 00 00) as opposed to 3 (66 31 C0).