X86 ENTER: What’s That Second Parameter?

[Raymond Chen] wondered why the x86 ENTER instruction had a strange second parameter that seems to always be set to zero. If you’ve ever wondered, [Raymond] explains what he learned in a recent blog post.

If you’ve ever taken apart the output of a C compiler or written assembly programs,  you probably know that ENTER is supposed to set up a new stack frame. Presumably, you are in a subroutine, and some arguments were pushed on the stack for you. The instruction puts the pointer to those arguments in EBP and then adjusts the stack pointer to account for your local variables. That local variable size is the first argument to ENTER.

The reason you rarely see it set to a non-zero value is that the final argument is made for other languages that are not as frequently seen these days. In a simple way of thinking, C functions live at a global scope. Sure, there are namespaces and methods for classes and instances. But you don’t normally have a C compiler that allows a function to define another function, right?

Turns out, gcc does support this as an extension (but not g++). However, looking at the output code shows it doesn’t use this feature, but it could. The idea is that a nested function can “see” any local variables that belong to the enclosing function. This works, for example, if you allow gcc to use its extensions:

#include <stdio.h>

void test()
{
   int a=10;
   /* nested function */
   void testloop(int n)
   {
      int x=a;
      while(n--) printf("%d\n",x);
   }
   testloop(3);
   printf("Again\n");
   testloop(2);
   printf("and now\n");
   a=33;
   testloop(5);
}

void main(int argc, char*argv[])
{
   test();
}

Continue reading “X86 ENTER: What’s That Second Parameter?”

Wandering Through Old Word Processors Yields A Beast

The world once ran on hardcopy, and when the digital age started to bring new tools and ways of doing things, documents were ripe for change. Today, word processors and digital documents are so ubiquitous that they are hardly worth a thought, but that didn’t happen all at once. [Cathode Ray Dude] has a soft spot for old word processors and the journey they took over decades, and he walks through the Olivetti ETV 2700.

In the days of character displays and no multitasking, WYSIWYG as a concept was still a long ways off.

The ETV 2700 is a monstrous machine; a fusion of old-school word processor, x86-based hardware, and electric 17 inch-wide typewriter.

With it one could boot up a word processor that is nothing like the WYSIWYG of today, write and edit a document, and upon command, the typewriter portion could electronically type out a page. A bit like a printer, but it really is an electric typewriter with a computer interface. Characters were hammered out one at a time with daisy wheel and ink ribbon on a manually-loaded page using all the usual typewriter controls.

While internally the machine has an x86 processor, expects a monitor and even boots MS-DOS, the keyboard had its own layout (and even proprietary keys and functions), did not support graphical output, and in other ways was unusual even by the standards of the oddball decades during which designers and products experimented with figuring out what worked best in terms of functionality and usability.

Nowadays, we see AI-enabled typewriter projects and porting vintage OSes to vintage word processor hardware, but such projects are in some part possible in part thanks to the durability of these devices. The entire video is embedded below, but you can jump directly to what the Olivetti ETV 2700 looked like on the inside if that’s what interests you most.

Continue reading “Wandering Through Old Word Processors Yields A Beast”

Emulating X86 On Apple’s AARCH64 X64 Emulator

You might know [Evan Martin] as the developer of retrowin32. It’s a Windows and x86 emulator designed to run on a Mac or on the web. He’s recently been exploring how to run 32-bit x86 binaries on the AArch64 (aka ARM64) architecture.

[Evan] realized that Apple’s ARM-based Macs feature a high-quality x86 emulator, used via the Rosetta binary translation system. It only supports 64-bit x86-64 binaries, also known as x64, and thus he had initially discounted it for running older 32-bit x86 software. However, as it turns out, x64 features a special compatibility mode for running 32-bit code. [Evan] was able to leverage this to run 32-bit Windows executables rather neatly via the high-performance Rosetta emulator.

To run a 32-bit executable on a 64-bit processor in this way, one creates a 64-bit program that is tasked with loading the 32-bit executable. It’s a little fussy, involving some tricks to handle memory management between the 32-bit code and the 64-bit wrapper, and how to interface with the OS, but [Evan] explains deftly how it’s all done.

[Evan] notes that this hack may not work forever, especially if Apple changes or deprecates Rosetta’s remaining x86-64 emulation in the future. Regardless, Apple’s “Game Porting Toolkit” relies on similar techniques used by Wine. If you find yourself dancing across platforms, you might learn some nifty tricks from [Evan]’s example!

Behind The X86 Pipeline Curtain

We’ve often heard that modern x86 CPUs don’t really execute x86 instructions. Instead, they decode them into RISC instructions that are easier to schedule, pipeline, and execute. But we never really looked into that statement to see if it is true. [Fanael] did, though, and the results are very interesting.

The post starts with a very simple loop containing four instructions. In a typical RISC CPU — RISC-V — the same loop requires six instructions. However, a modern CPU is likely to do much more than just blindly convert one instruction set to another.

Continue reading “Behind The X86 Pipeline Curtain”

BIOS POST Card Built Using Raspberry Pi Pico

A computer’s BIOS includes basic diagnostic tools for troubleshooting issues. Often, we rely on the familiar beeps from the POST system for this reason. However, error codes are also available via hardware “POST Cards” that were particularly popular in the 1990s. [Mr. Green] has now built a POST card using readily-available modern hardware.

[Mr. Green] built the device to help troubleshoot an x86 based firewall appliance that was having trouble. Like many x86 systems, it featured a Low Pin Count (LPC) bus which can be used to capture POST troubleshooting codes. By hooking up a Raspberry Pi Pico to the LPC bus on the firewall’s motherboard, it was possible to get it to display the POST error codes on some LEDs. This is of great use in the absence of a conventional PC speaker to sound the error out with beeps.

The build can be used for POST-based troubleshooting on any x86 system with an LPC bus. Files are on Github for those eager to replicate the build. We’ve seen similar work before, too. Video after the break.

Continue reading “BIOS POST Card Built Using Raspberry Pi Pico”

Intel Suggests Dropping Everything But 64-Bit From X86 With Its X86-S Proposal

In a move that has a significant part of the internet flashing back to the innocent days of 2001 when Intel launched its Itanium architecture as a replacement for the then 32-bit only x86 architecture – before it getting bludgeoned by AMD’s competing x86_64 architecture – Intel has now released a whitepaper with associated X86-S specification that seeks to probe the community’s thoughts on it essentially removing all pre-x86_64 features out of x86 CPUs.

While today you can essentially still install your copy of MSDOS 6.11 on a brand-new Intel Core i7 system, with some caveats, it’s undeniable that to most users of PCs the removal of 16 and 32-bit mode would likely go by unnoticed, as well as the suggested removal of rings 1 and 2, as well as range of other low-level (I/O) features. Rather than the boot process going from real-mode 16-bit to protected mode, and from 32- to 64-bit mode, the system would boot straight into the 64-bit mode which Intel figures is what everyone uses anyway.

Where things get a bit hazy is that on this theoretical X86-S you cannot just install and boot your current 64-bit operating systems, as they have no concept of this new boot procedure, or the other low-level features that got dropped. This is where the Itanium comparison seems most apt, as it was Intel’s attempt at a clean cut with its x86 legacy, only for literally everything about the concept (VLIW) and ‘legacy software’ support to go horribly wrong.

Although X86-S seems much less ambitious than Itanium, it would nevertheless be interesting to hear AMD’s thoughts on the matter.

A Cycle-Accurate Intel 8088 Core For All Your Retro PC Needs

A problem faced increasingly by retrocomputer enthusiasts everywhere is the supply of chips. Once a piece of silicon goes out of production its demand can be supplied for a time by old stock and second hand parts, but as they become rare so the cost of what can be dubious parts accelerates out of reach. Happily for CPUs at least, there’s a ray of hope in the form of FPGA-based cores which can replace the real thing, and for early PC owners there’s a new one from [Ted Fried]. MCL86 is a cycle accurate Intel 8088 FPGA Core that can be used within an FPGA design or as a standalone in-circuit replacement for a real 8088. It even has a full-speed mode that sacrifices cycle accuracy and can accelerate those 8088 instructions by 400%.

Reading the posts on his blog, it’s clear that this is a capable design, and it’s even been extended with a mode that adds cache RAM to mirror the system memory at the processor’s speed. You can find all the code in a GitHub repository should you be curious enough to investigate for yourself. We’ve pondered in the past where the x86 single board computers are, perhaps it could be projects like this that provide some of them.