Recent posts

#1

Work in progress / Re: Code Density Comparison of...

Last post by PabloMack - Today at 01:48:35 AM

So - what actual hardware or hardware emulator is running your ϕEngine?
Using ARM?, QEMU,  custom FPGA?

John Z

I am writing a simulator I call ϕSim that runs on Windows. It's main purpose is to prove out the logic of how it works. I have been using OpenWatcom for writing the SW tool chain but it only runs on 32-bit x86. That's why I have been evaluating PellesC for 64-bit execution. I am also evaluating TileLink for writing a soft core to run as a standalone SOC. Of course I will have to prove it out on an FPGA. So far I am impressed with TL as it is open source and has growing support. It is the primary environment for RISC-V. But TL is not married to RISC-V and I think it could serve ϕEngine quite well.

ϕEngine's instruction set was developed and is maintained by a program I started writing in 2018. It generates C source code for the assembler (ϕAsm) as well as for ϕSim. I plan to generate Verilog source code to define the soft core and SOC. This is the natural place to do it since it has direct access to the data structures that define ϕEngine's instruction set.

#2

General discussion / Re: Top Programming languages ...

Last post by PabloMack - Today at 01:29:11 AM

Sorry, I don't know enough about Rust to have a strong opinion. Over the years I have seen enough programming languages being described as "the next big thing" only to disappear after a few years. By now I'm old and skeptical enough to wait a while for things to clear up...

In my opinion there are better ways to make "most" uses of arrays and pointers safer than the way Rust does it. Purportedly, the compilation process can be horribly compute-intensive with all of the checking that has to happen. Then the build process seems to be radically different from that in the C world. I think the best way to make arrays and pointers safer is to add higher-level features to the language that will hide their use so that programmers don't have to deal with raw pointers any more. Seems that Rust tries do manage what is done with raw pointers using the Borrow Checker. Not the way to go in my opinion.

#3

Assembly discussions / Extracting binary data with Po...

Last post by Vortex - July 26, 2026, 10:06:02 AM

Simple method to extract binary executable data with Poasm. The procedure WriteFileToDisc saves the code between the two labels, MsgBox and start. This method is useful to call assembly code from languages like RapidQ Basic with no inline assembly support.

Code Select Expand

.386
.model flat,stdcall
option casemap:none

ExitProcess PROTO :DWORD

WriteFileToDisc PROTO :DWORD,:DWORD,:DWORD

.data

fname       db 'MsgBox.bin',0

.code

MsgBox:

    call    delta

delta:

    pop     edx
    mov     eax,OFFSET delta
    sub     edx,eax
    lea     eax,[edx+capt]
    lea     ecx,[edx+msg]

;   call    MessageBox

    push    0
    push    eax
    push    ecx
    push    0
    call    DWORD PTR [esp+20]
   
    retn    16

capt    db 'Hello',0
msg     db 'This is a test.',0

start:

ProcLen EQU start-MsgBox

    invoke  WriteFileToDisc,ADDR fname,\
            MsgBox,ProcLen
           
    invoke  ExitProcess,0

END start

Running the executable, it creates the file MsgBox.bin

RapidQ Basic code calling the embedded binary data :

Code Select Expand

$APPTYPE GUI

DIM s AS STRING

DIM pMessageBox as INTEGER

DECLARE FUNCTION CallWindowProc LIB "user32" ALIAS "CallWindowProcA" _
                 (Proc AS LONG, p1 AS LONG, p2 AS LONG, p3 AS LONG, _
                 p4 AS LONG) AS LONG

DECLARE FUNCTION GetProcAddress LIB "kernel32" ALIAS "GetProcAddress" (hModule AS LONG, lpProcName AS STRING) AS LONG
DECLARE FUNCTION LoadLibrary LIB "kernel32" ALIAS "LoadLibraryA" (lpFileName AS STRING) AS LONG

DefInt ptrMsgBox

FUNCTION MsgBox1(pointer As Long) As Long
    Result=CallWindowProc(ptrMsgBox,pointer,0,0,0)
END FUNCTION

$RESOURCE ResourceName AS "MsgBox.bin"

DIM Mem AS QMEMORYSTREAM

Mem.ExtractRes(Resource(0))
Mem.Position=0
s=Mem.ReadBinStr(Mem.Size)

ptrMsgBox=varptr(s)

pMessageBox = GetProcAddress(LoadLibrary("user32.dll"), "MessageBoxA")

MsgBox1(pMessageBox)

Compiling the RapidQ code :

Code Select Expand

RC.EXE -LC:\Rapidq\lib MBox.bas

#4

Work in progress / Re: Code Density Comparison of...

Last post by John Z - July 25, 2026, 09:04:34 AM

So - what actual hardware or hardware emulator is running your ϕEngine?
Using ARM?, QEMU,  custom FPGA?

John Z

#5

ARM64 discussions / Re: Not frustrated enough? Too...

Last post by PabloMack - July 24, 2026, 09:42:57 PM

I think it is a good thing to understand (and even discuss) the limitations of everything you use. Otherwise there will likely never be improvement.

#6

ARM64 discussions / Re: Not frustrated enough? Too...

Last post by TimoVJL - July 24, 2026, 08:10:53 PM

Pelles C C-compiler support ARM64, why not just use it.
An assembler is just for making some useful functions using CPU in best way.

#7

ARM64 discussions / Re: Not frustrated enough? Too...

Last post by PabloMack - July 24, 2026, 04:21:24 PM

The gymnastics that ARM64 has to go through to come up with these string addresses is amazingly bad.

#8

Work in progress / Code Density Comparison of two...

Last post by PabloMack - July 23, 2026, 04:35:45 AM

I just rewrote an assembly function for the Pelles C assembler that compares two unsigned 24-bit integers. The function returns 1 for greater, 0 for equal and -1 for less than. I thought some of you might find it interesting. The x64 version was 45 bytes in size. I wrote a ϕEngine version and it is 15 bytes, only 1/3 the size. But this should not be surprising since ϕEngine can process 3-byte integers natively. Here is the source code:

 ⅅCPU Eng32
ut_cmp‡: ⅅPBeg
    ld     ⓊQ0,ut:(Ⓡ0)
    cmp    ⓊQ0,ut:(Ⓡ1)
    s.A*   Ⓒ0,ⓊQ0
    s.B*   Ⓒ0,ⓈQ0
    rts
 ⅅPEnd

Notice that the processing has to be done in a 32-bit register (ⓊQ0) which also is used to hold the return value. The two source values are extended during the loads so there are no separate conversion routines. The second load is part of the compare instruction. Most of the code is for producing a return value from the flags that are set by the compare. Since this operation can be done inline cheaper than even just the setup for a function call, the function would actually never be needed in ϕPPL or ϕAsm.

#9

General discussion / Re: Pelles C and Windows Defen...

Last post by John Z - July 22, 2026, 11:20:48 PM

Yes, Pelles C is very flexible that way.

However the Windows 'Protections' are not limited to programs installed just into the Windows preferred directories.  When enabled they are system wide.  If one maxes out the protections probably the only place to get programs is the M$S windows store....

John Z

#10

Work in progress / Re: High Performance 64-bit CP...

Last post by PabloMack - July 22, 2026, 08:43:36 PM

I applaud your ambition!  Other than my experience with Xilinx FPGA, many years ago, it is way way out of my zone.  But I look forward to trying it someday.

John Z

Are you limiting your possible collaborators by requiring LinkedIn? I stayed away from it, and especially after it became an arm of Micro$oft...

I share your sentiment about LinkedIn and MicroSoft. 😁