The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

    Mastodon

  • Twitter Updates

  • My Flickr Stream

    20140508-Delphi-2007--Project-Options--Cannot-Edit-Application-Title-HelpFile-Icon-Theming20140430-Fiddler-Filter-Actions-Button-Run-Filterset-now20140424-VMware-Fusion-6.0.3.-no-reclaimable
    More Photos

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,860 other subscribers

Archive for the ‘x86’ Category

« Previous Entries
Next Entries »

The fundamentals of programming, a thread by @isotopp on Twitter

Posted by jpluimers on 2023/03/22

Kristian Kohntöpp publishes great DevOps related threads on Twitter. [Wayback/Archive] Thread by @isotopp “I am Kris, and I am 53 now. I learned programming on a Commodore 64 in 1983. My first real programming language (because C64 isn’t one) was 6502 assembler, forwards and backwards. “ is his response, about a year and a half ago, to a request by Julia Evans (@b0rk) that I also saved: [Wayback/Archive] Thread by @b0rk on Thread Reader App – Thread Reader App.

Her request: [Archive] 🔎Julia Evans🔍 on Twitter: “if you’ve been working in computing for > 15 years — are there fundamentals that you learned “on the job” 15 years ago that you think most people aren’t learning on the job today? (I’m thinking about how for example nobody has ever paid me to write C code)” / Twitter followed by [Archive] 🔎Julia Evans🔍 on Twitter: “I’m especially interested in topics that are still relevant today (like C programming) but are just harder to pick up at work now than they used to be” / Twitter.

The start of his thread is [Archive] Kris on Twitter: “@b0rk I am Kris, and I am 53 now. I learned programming on a Commodore 64 in 1983. My first real programming language (because C64 isn’t one) was 6502 assembler, forwards and backwards.” / Twitter.

Kristian’s story is very similar to mine, though I sooner stepped up the structured programming language ladder as at high school, I had access to an Apple //e with a Z80 card (yes, the SoftCard), so could run CP/M with Turbo Pascal 1.0 (later 2.0 and 3.0) which I partly described in The calculators that got me into programming (via: calculators : Algorithms for the masses – julian m bucknall), followed by early access at the close by university to PC’s running on 8086 and up. The computer science lab, now called Snellius, but back then known as CRI for Centraal RekenInstituut – is now had an educational deal with IBM, which means they switched from the PC/XT to the PC/AT with a 80286 processor as soon as the latter came out).

Read the rest of this entry »

Posted in 6502 Assembly, Assembly Language, Development, ESP32, ESP8266, Software Development, x86 | Leave a Comment »

Very useful link: Software optimization resources. C++ and assembly. Windows, Linux, BSD, Mac OS X

Posted by jpluimers on 2023/02/14

If I ever need to go deep into optimisation again, there is lots I can still learn from [Wayback/Archive] Software optimization resources. C++ and assembly. Windows, Linux, BSD, Mac OS X

Thanks [Archive] Kris on Twitter: “@Kharkerlake @unixtippse Agner Fog ist eigentlich ein Anthropologe, aber er reversed interne Strukturen von Intel CPUs, und …, speziell 3. The microarchitecture of Intel, AMD and VIA CPUs: An optimization guide for assembly programmers and compiler makers ist die HPC Bibel.” / Twitter!

Must watch video with Agner about Warlike and Peaceful Societies below the signature.

–jeroen

Read the rest of this entry »

Posted in Assembly Language, C++, Development, Software Development, x64, x86 | Leave a Comment »

When floating point code suddenly becomes orders magnitudes slower (via C++ – Why does changing 0.1f to 0 slow down performance by 10x? – Stack Overflow)

Posted by jpluimers on 2022/01/26

When working with converging algorithms, sometimes floating code can become very slow. That is: orders of magnitude slower than you would expect.

A very interesting answer to [Wayback] c++ – Why does changing 0.1f to 0 slow down performance by 10x? – Stack Overflow.

I’ve only quoted a few bits, read the full question and answer for more background information.

Welcome to the world of denormalized floating-point! They can wreak havoc on performance!!!

Denormal (or subnormal) numbers are kind of a hack to get some extra values very close to zero out of the floating point representation. Operations on denormalized floating-point can be tens to hundreds of times slower than on normalized floating-point. This is because many processors can’t handle them directly and must trap and resolve them using microcode.

If you print out the numbers after 10,000 iterations, you will see that they have converged to different values depending on whether 0 or 0.1 is used.

Basically, the convergence uses some values closer to zero than a normal floating point representation dan store, so a trick is used called “denormal numbers or denormalized numbers (now often called subnormal numbers)” as described in Denormal number – Wikipedia:

…

In a normal floating-point value, there are no leading zeros in the significand; rather, leading zeros are removed by adjusting the exponent (for example, the number 0.0123 would be written as 1.23 × 10−2). Denormal numbers are numbers where this representation would result in an exponent that is below the smallest representable exponent (the exponent usually having a limited range). Such numbers are represented using leading zeros in the significand.

…

Since a denormal number is a boundary case, many processors do not optimise for this.

–jeroen

Posted in .NET, Algorithms, ARM, Assembly Language, C, C#, C++, Delphi, Development, Software Development, x64, x86 | Leave a Comment »

Some notes on loosing performance because of using AVX

Posted by jpluimers on 2019/03/20

It looks like AVX can be a curse most of the times. Below are some (many) links that lead me to this conclusion, based on a thread started by Kelly Sommers.

My conclusion

Running AVX instructions will affect the processor frequency, which means that non-AVX code will slow down, so you will only benefit when the gain of using AVX code outweighs the non-AVX loss on anything running on that processor in the same time frame.

In practice, this means you need to long term gain from AVX on many cores. If you don’t, then the performance penalty on all cores, including the initial AVX performance, will degrade, often a lot (dozens of %).

Tweets and pages linked by them

Kelly raised a bunch of interesting questions and remarks because of the above:

I collected the above links because of [WayBack] GitHub – maximmasiutin/FastMM4-AVX: FastMM4 fork with AVX support and multi-threaded enhancements (faster locking), where it is unclear which parts of the gains are because of AVX and which parts are because of other optimizations. It looks like that under heavy loads on data center like conditions, the total gain is about 30%. The loss for traditional processing there has not been measured, but from the above my estimate it is at least 20%.

Full tweets below.

Read the rest of this entry »

Posted in Assembly Language, Development, Software Development, x64, x86 | Leave a Comment »

performance – Why is this C++ code faster than my hand-written assembly for testing the Collatz conjecture? – Stack Overflow

Posted by jpluimers on 2019/02/28

Geek pr0n at [WayBack] performance – Why is this C++ code faster than my hand-written assembly for testing the Collatz conjecture? – Stack Overflow

Via: [WayBack] Very nice #Geekpr0n “Why is C++ faster than my hand-written assembly code?” The comments are of high quality i… – Jan Wildeboer – Google+

–jeroen

Posted in Assembly Language, C, C++, Development, Software Development, x64, x86 | Leave a Comment »

A refefernce to 6502 by “Remember that in a stack trace, the addresses are return addresses, not call addresses – The Old New Thing”

Posted by jpluimers on 2018/09/11

On x86/x64/ARM/…:

It’s where the function is going to return to, not where it came from.

And:

Bonus chatter: This reminds me of a quirk of the 6502 processor: When it pushed the return address onto the stack, it actually pushed the return address minus one. This is an artifact of the way the 6502 is implemented, but it results in the nice feature that the stack trace gives you the line number of the call instruction.

Of course, this is all hypothetical, because 6502 debuggers didn’t have fancy features like stack traces or line numbers.

Source: [WayBack] Remember that in a stack trace, the addresses are return addresses, not call addresses – The Old New Thing

Which resulted in these comments at [WayBack] CC +mos6502 – Jeroen Wiert Pluimers – Google+:

  • mos6502: And don’t forget the crucial difference in PC on 6502 between RTS and RTI!
  • Jeroen Wiert Pluimers: +mos6502 I totally forgot about that one. Thanks for reminding me
    <<Note that unlike RTS, the return address on the stack is the actual address rather than the address-1.>>

References:

[WayBack] 6502.org: Tutorials and Aids – RTI

RTI retrieves the Processor Status Word (flags) and the Program Counter from the stack in that order (interrupts push the PC first and then the PSW).

Note that unlike RTS, the return address on the stack is the actual address rather than the address-1.

[WayBack] 6502.org: Tutorials and Aids – RTS

RTS pulls the top two bytes off the stack (low byte first) and transfers program control to that address+1. It is used, as expected, to exit a subroutine invoked via JSR which pushed the address-1.

RTS is frequently used to implement a jump table where addresses-1 are pushed onto the stack and accessed via RTS eg. to access the second of four routines.

–jeroen

Posted in 6502, 6502 Assembly, Assembly Language, Development, History, Software Development, The Old New Thing, Windows Development, x64, x86 | Leave a Comment »

How to check if a binary is 32 or 64 bit on Windows? – Super User

Posted by jpluimers on 2018/08/17

It seems there are a few, but only loading the binary is the sure method to know what the process will be using: [WayBack] How to check if a binary is 32 or 64 bit on Windows? – Super User and [WayBack] How do I determine if a .NET application is 32 or 64 bit? – Stack Overflow.

Details in the answers of these questions, here are a few highlights:

  • The first few characters in the binary header reveal what it was originally designed for.
  • A .NET executable might still have an x64 header for bootstrapping.
  • The Windows SDK has a tool dumpbin.exe with the /headers option.
  • You can use sigcheck.exe from SysInternals.
  • The file utility (e.g. from cygwin, which comes with msysgit) will distinguish between 32- and 64-bit executables.
  • Use the command line 7z.exe on the PE file (Exe or DLL) in question which gives you a CPU line.
  • Virustotal File detail is a way to find out if a binary is 32 bit or 64 bit.
  • Even an executable marked as 32-bit can run as 64-bit if, for example, it’s a .NET executable that can run as 32- or 64-bit. For more information see https://stackoverflow.com/questions/3782191/how-do-i-determine-if-a-net-application-is-32-or-64-bit, which has an answer that says that the CORFLAGS utility can be used to determine how a .NET application will run.

–jeroen

Search terms: win64, win32, x64, x86_64, x86

Posted in Assembly Language, Development, Power User, Windows, x64, x86 | Leave a Comment »

Grammar Zoo – Browsable Borland Delphi Assembler Grammar

Posted by jpluimers on 2018/06/12

Interesting: [WayBack] Grammar Zoo – Browsable Borland Delphi Assembler Grammar.

It is very complete, including constructs like the [WayBack] special directives VMTOFFSET and DMTINDEX for Delphi virtual and dynamic methods.

You can contribute to it using https://github.com/slebok/zoo/tree/master/zoo/assembly/delphi

–jeroen

Posted in Assembly Language, Delphi, Development, Software Development, x86 | Leave a Comment »

Mixing x64 Outlook with x86 Delphi: never a good idea…

Posted by jpluimers on 2018/02/07

Via [WayBack] Hi all,I’m a bit stuck here with a “simple” task.Looks like Outlook 2016 doesn’t supports “MAPISendMail”, at least, if i trigger this, Thunderbird… – Attila Kovacs – Google+:

Basically only MAPISendMail works cross architecture and only if you fill all fields.

This edited [WayBack] email – MAPI Windows 7 64 bit – Stack Overflow answer by [WayBack] epotter is very insightful (thanks [WayBack] Rik van Kekem – Google+):

Calls to MAPISendMail should work without a problem.

For all other MAPI method and function calls to work in a MAPI application, the bitness (32 or 64) of the MAPI application must be the same as the bitness of the MAPI subsystem on the computer that the application is targeted to run on.

In general, a 32-bit MAPI application must not run on a 64-bit platform (64-bit Outlook on 64-bit Windows) without first being rebuilt as a 64-bit application.

For a more detailed explanation, see the MSDN page on Building MAPI Applications on 32-Bit and 64-Bit Platforms

–jeroen

Posted in Delphi, Delphi x64, Development, Office, Outlook, Power User, Software Development, x86 | Leave a Comment »

Compiler Explorer – how various C++ compilers translate code into various machine code targets

Posted by jpluimers on 2017/01/03

The first implementation of Compiler Explorer supports many versions of the gcc, clang and icc compilers on ARM, ARM64, AVR and x86 targets.

On the left you type your C++ code, on the right you see the resulting assembler code optionally with byte code and colorised so you can correlate the C++ lines with the assembly.

A great way to start the year: learning new things!

Related:

–jeroen

via:

Some videos:

Read the rest of this entry »

Posted in ARM, Assembly Language, C++, Conference Topics, Conferences, Development, Event, Software Development, x86 | Leave a Comment »

« Previous Entries
Next Entries »