News: 1751959751

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

Microsoft developer ported vector database coded in SAP’s ABAP to the ZX Spectrum

(2025/07/08)


A Microsoft senior software engineer named Alice Vinogradova has ported a database she wrote in SAP’s ABAP language to the venerable Z80 processor that powered the Sinclair ZX Spectrum – and marveled at the results.

Vinogradova’s named her database ZVDB-Z80 and describes it as “a Vector Database developed entirely in ABAP, designed to offer an independent solution without relying on external vector databases.”

ABAP (born 1983) and Z80 (born 1976) are practically contemporaries

ABAP, aka Advanced Business Application Programming, is the programming language ERP behemoth SAP created to write apps for its platform.

Naturally, the code is on [1]GitHub , where the engineer [2]explained that “Last month, I was cleaning up old code and rediscovered ZVDB.”

When Vinogradova reconsidered ZVDB, she “had a realization that made me smile.”

[3]

“ABAP (born 1983) and Z80 (born 1976) are practically contemporaries,” she wrote. “They grew up in the same era of computing—when memory was precious, cycles were counted, and every byte mattered.”

[4]

[5]

Vinogradova appreciates the tricks developers needed to use to create good software despite those constraints.

“When I built ZVDB, I deliberately applied every Z80 optimization I knew,” she wrote. “Why? Because these ‘old’ techniques are timeless – they just happen to make modern code blazingly fast.”

[6]

So she used them again while re-writing ZVDB in Z80 assembly language, and claims that when running on the vintage CPU her code ran “Only 3-6x slower despite 857x clock speed difference.”

[7]Christmas 1984: The last hurrah for 8-bit home computers

[8]Open source Z80 clone seeks to help bring classic chip back from the dead

[9]The New ROM Antics – building the ZX Spectrum 128

[10]Tales from four decades in the Sinclair aftermarket: Parts, upgrades and party tricks

Vinogradova doesn’t think that’s a massive surprise. “These optimizations were born for the Z80. They just happen to be universally optimal,” she wrote, before explaining why she feels Z80 thinking “Still wins in 2025”.

Every Z80 lesson I applied to ABAP remains valid on modern hardware:

Lookup tables are always faster than calculation

Z80: Save those precious cycles

Modern CPU: Cache-friendly access patterns

Sequential memory access is king

Z80: One cycle vs four for random access

HANA: Columnar storage loves sequential patterns

Bit operations are universal

Z80: Native CPU instructions

Modern CPU: SIMD does the same thing, faster

Pre-computation beats runtime math

Z80: Can't afford to calculate

Modern systems: Why calculate what you can remember?

“Those years with Z80 assembly weren't just nostalgia—they were training,” she added. “Every cycle counted then, and guess what? Every cycle still counts now. The scale changed. The principles didn't.”

“When I port this to HANA AMDP, it'll be even faster. Because AMDP will take my Z80-optimized algorithm and parallelize it. But the core insight—lookup beats calculation, sequential beats random—that came from 1976.”

Her GitHub page of course includes the code discussed here, plus instructions on how to get it running on an actual Sinclair ZX Spectrum, online emulators [11]JSSpeccy or [12]Qaop/JS , or on local emulators [13]Fuse , [14]ZEsarUX , [15]Speccy , or [16]Retro Virtual Machine .®

Get our [17]Tech Resources



[1] https://github.com/oisee/zvdb-z80

[2] https://github.com/oisee/zvdb-z80/blob/master/ZVDB-Z80-ABAP.md

[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aGzsPefv4Vt4M14MboMzFwAAAEc&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0

[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aGzsPefv4Vt4M14MboMzFwAAAEc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aGzsPefv4Vt4M14MboMzFwAAAEc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0

[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aGzsPefv4Vt4M14MboMzFwAAAEc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0

[7] https://www.theregister.com/2024/12/28/christmas_1984_home_computers/

[8] https://www.theregister.com/2024/04/29/open_source_z80_clone/

[9] https://www.theregister.com/2024/01/15/opinion_column_zxspectrum_128/

[10] https://www.theregister.com/2023/01/20/retro_tech_week_rwap/

[11] https://jsspeccy.zxdemo.org/

[12] http://torinak.com/qaop/en

[13] http://fuse-emulator.sourceforge.net/

[14] https://github.com/chernandezba/zesarux

[15] https://fms.komkon.org/Speccy/

[16] http://www.retrovirtualmachine.org/

[17] https://whitepapers.theregister.com/



One more for luck

steelpillow

Fond memories.

This from the RISC OS era:

Stick to one standard library and one standard set of library calls. Don't have a thousand apps stashing a thousand and ten sometimes-identical libraries under their armpits, to do exactly the same job.

Re: One more for luck

disk iops

But then you'd have to smash the fingers of the know it all youts who worship shiny and force them to actually learn the fundamentals, that are hard. Instead of letting them get away with rewriting things in python and thinking that are now programmers.

Wot no CoPilot?

Fruit and Nutcase

I expect she'll be sent to re-education camp for not using CoPilot.

Yes, the old constraints did mean we took much more care over what our code did under the covers. The modern solution is to put more processing power at the problem.

icon: a beer, or wine, or whatever her chosen poison for her efforts

Re: Wot no CoPilot?

b0llchit

Don't worry, we'll get that smart-ass thinking eliminated soon enough.

Who do they think they are, those old school coders? They are nothing compared to modern times. They are just relics trying to show off and suppress the progress we've been making at eliminating those thinkers. Don't worry, they'll be dead soon enough and our automated way will be the only way.

/s

Z80: One cycle vs four for random access

brainwrong

That's not true, not for the original 40pin Z80 used in the ZX81 etc. It may be true for the later Z800000000.

Re: Z80: One cycle vs four for random access

Dan 55

I think it means "INC HL" is cheaper than "LD HL, n" if you're doing e.g. "LD A, (HL)" afterwards.

Maybe you could [1]abuse the stack pointer for something cheaper still, depending on the kind of data.

[1] https://blog.stevewetherill.com/2022/02/more-sidewize-and-some-cool-cspect-stuff.html

I spy an optimization

Dan 55

From [1]this page , the following code:

next_byte:

LD A, (DE) ; Vector B

XOR (HL) ; Vector A

[...]

DEC B

JR NZ, next_byte

RET

"DEC B ; JR NZ next_byte" should be "DJNZ next byte". The first method takes 16 (non-zero) or 11 (zero) T-States. DJNZ takes 13 (non-zero) or 8 (zero) or T-States.

[1] https://github.com/oisee/zvdb-z80/blob/master/ZVDB-Z80-ABAP.md

And yet...

Yorick Hunt

... Microsoft struggles to port code from Windows 10 to Windows 11.

Re: And yet...

b0llchit

Because they are targeting the wrong processor...

Re: And yet...

Dan 55

[1]Imagine a Beowulf cluster of these .

[1] https://www.youtube.com/watch?v=940L9_7h22o

Doctor Syntax

Aren't her points 1 & 4 the same?

Aren't her points 1 & 4 the same?

Anonymous Coward

I am guessing one point was for pre computed tables compiled into the executable and the other for tables calculated at run time possibly based on run time parameters; although in the latter case memoization might save both space and time (calculate as needed, cache [memoize] against future need.)

I would prefer getting the code right before making it fast - not that Microsoft is often guilty of either infraction separately and never jointly.

" Premature optimisation is the root of all evil. " Knuth 1974.

Premature optimisation

Ken Shabby

It’s never happened before, I promise.

Re: Premature optimisation

Anonymous Coward

So true for modern software ... just throw MORE CPU/GPU at it and lots & lots of memory.

:)

Re: Aren't her points 1 & 4 the same?

Anonymous Coward

Loved this because it is so 'Right' to use the CPU to the maximum.

"Premature optimisation is the root of all evil." Knuth 1974."

Quoting IT 'Gods' does not make it True in ALL cases.

For small well known pieces of code where you KNOW exactly the program flow through that code you WILL optimise the code to the maximum you can, IF the optimisations are necessary.

P.S.

I am all for writing fast optimised code IF required ... this does not mean it should be undocumented or spagetti-code.

It is lazy to simply throw MORE CPU/GPU at it and use more & more memory because it is QUICK to do.

Look at the HUGE size of the software we use now.

[Hard hat MODE on ... smashing control with LARGE hammer so it cannot be switched off !!!]

:)

wolfetone

I do still work like I have 56k dial up at home, and it's sad to see how many people don't think like that and instead think everyone has superfast machines and things like that.

Eeek

Anonymous Coward

Hmmm so you suggesting that proper skillful intelligent programming can produce very fast processing on very moderate hardware.

But that would reasult in an awful lot of overpriced shit being completely unnecessary and on having skillful intelligent programmers not just minimum wage slaves producing junk code by the kilo using AI.

I would suggest that until this article is long forgotten you avoid high buildings and open windows

Anonymous Coward

The grand children got an Xbox with 500GB storage the other day. I naively thought 500GB storage would be plenty. Three games later and they've filled it.

Famous, adj.:
Conspicuously miserable.
-- Ambrose Bierce, "The Devil's Dictionary"