View unanswered posts | View active topics It is currently Thu Mar 28, 2024 8:51 am



Reply to topic  [ 21 posts ]  Go to page 1, 2  Next
 KISC: TTL-Processor with "Koyaanisqatsi" Instruction Set 
Author Message
User avatar

Joined: Sat Feb 13, 2021 12:22 pm
Posts: 10
Location: https://en.wikipedia.org/wiki/Tashkent
Planning of this processor started from idea about an abbreviatured byte-code, where two nibbles of byte is optimal transparent for human perception in dump, but also it must to facilitate developing any algorythm without a translators. In this way byte A1 mean the use register A₁ or byte 3D mean the ALU-operation "bitwise Disjunction" using operand register with index #3, where byte AB mean operands "A₁,B₃", summary «A1 AB 3D» as «A1 A,B3 D» decoded like «Disj A₁,B₃».

First design started since 2019 in Logisim just as fun joke, but with time the conception is developed in more serious CISC project with Turing completeness, which ready for building on most CPLD/FPGA as homebrew Central Processor Unit.

Instruction Set:
  • 00¹ - HALT: Halt the computing
  • 01…99 - 99 BCD-codes like 99 Byte-Code-Data as prefixes
  • 0A…9A - ALU-operation Add (add r,t/m)
  • 0B…9B - ALU-operation suBtract (sub r,t/m)
  • 0C…9C - ALU-operation Conjunct (and r,t/m)
  • 0D…9D - ALU-operation Disjunct (or r,t/m)
  • 0E…9E - ALU-operation Exclusive or (eor/xor r,t/m)
  • 0F…9F - ALU-operation For (mov r,t/m)
  • A0…A9 - Select register A₀…A₉ of Accumulators group (A₀ is PSW)
  • B0…B9 - Select register B₀…B₉ of memory Block group
  • C0…C9 - Select register C₀…C₉ of memory Cells group
  • D0…D9 - Select register D₀…D₉ of in/out Devices group
  • AA…AD - Set the band of operands from group «A,A», «A,B», «A,C», «A,D»
  • BA…BD - Set the band of operands from group «B,A», «B,B», «B,C», «B,D»
  • CA…CD - Set the band of operands from group «C,A», «C,B», «C,C», «C,D»
  • DA…DD - Set the band of operands from group «D,A», «D,B», «D,C», «D,D»
  • AE/AF² - Conditional execution «Analogous is Exist/False» by ZF/NZ of PSW
  • BE/BF² - Conditional execution «Bigger bit is Exist/False» by SF/NS of PSW
  • CE/CF² - Conditional execution «Carry if Exist/False» by CF/NC of PSW
  • E0…FF¹ - Extended Functions - «CALL 0xE000…0xFF00»
¹: Current address of Instruction Pointer saving to B₀:C₀ pair
²: Address for return loaded from B₀:C₀ pair

Register A₀ stores the PSW with bits:
  • Bit #0 - ZF / ZERO (result is equals 0)
  • Bit #1 - CF / CARRY
  • Bit #2 - PF / PARITY (modulo by 2) - reserved
  • Bit #3 - SF / MINUS

Examples:
Code:
1231 A1         |REG  A1             ;Use APR A₁ as Receiver
1232    AB      |ARG  A,B            ;Set APRs A,B as Receiver,Translator
1233          2D|DIS  A,B2           ;Bitwise Disjunction Receiver,Translator
--------------------------
1234 A1 AB    2D|OR   A1,B2          ;Bitwise Disjunction A₁ with B₂
1237 AB A1    3D|OR   A1,B3          ;Bitwise Disjunction A₁ with B₃
123A AC       4D|OR   A1,C4          ;Bitwise Disjunction A₁ with C₄
123C    A2    5D|OR   A2,C5          ;Bitwise Disjunction A₂ with C₅
123E       67 8D|OR   A2,[B6C6+7+C8] ;Bitwise Disjunction A₂ with memory cell
1240       67 A2|MOV  [B6C6+7],A2    ;Save to memory cell pointed by B₆C₆
1242       67 AB|XCHG A6,B7          ;Exchange two registers
1244          CF|RET  CF             ;Break and return to [B₀C₀] by flag CF
1245       67 CF|RET  CF,B6C6+7      ;Break and jump to [B₆C₆+7] by flag CF
1247          F1|CALL F1             ;Call Function #1 at 0xF100
1248       67 F1|CALL F167           ;Call Function #1 with option #67
124A       67 00|HLT  67             ;Call system function #67
124C          00|HLT                 ;System Halt


Basic project at GitHub and Habr(ru) (Step-By-Step(ru)).
Very raw Verilog-model at EDA-PlayGround.

P.S.: Sorry, but the project has not yet been translated into English…


Sat Feb 13, 2021 4:00 pm
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
Welcome, Alikberov! I did not expect to see a reference to an art film here, but I do appreciate it!

Thanks for the description and the links - I don't read Russian but Google Translate is doing quite well.

I like the idea of transparent machine code, where each nibble means something, and we don't much need an assembler or disassembler. I see there are 10 registers to be used as accumulators, and that's nice. And I see that the 10 B and 10 C registers are to be used as address pairs, and specifically for return addresses, in a kind of non-automatic stack. That's unusual - and therefore interesting too!


Sat Feb 13, 2021 5:26 pm
Profile
User avatar

Joined: Sat Feb 13, 2021 12:22 pm
Posts: 10
Location: https://en.wikipedia.org/wiki/Tashkent
My-self translation trying on Habr.
BigEd wrote:
I like the idea of transparent machine code
Among the multitude of different architectures that idea is not popular and byte-code always based by 16 or 8 with no humanity view.
I'm thinking, that Koy-Idea just must to be anyway, regardless of opportunity. :roll:

And the main idea is not in the concretic implementation itself, but in an attempt to develop a paradigm of humanitarian bytecode, when Artificial Intelligence already prevails around, but the processors continue to be esoteric, confusing and alien aweful to outside understanding!

Now experimental Verilog-model with multiticks spends upto 18 clock ticks on one instruction.
Attachment:
File comment: Waves of CPU-Module
cpu_graph.png
cpu_graph.png [ 41.57 KiB | Viewed 2040 times ]

That versions is haven't Register File and all APRs directrly placed in RAM with many different Machine Cycles:
  • Mend - Get Instruction Code
  • M₀ - Get A₀ (PSW)
  • M₁ - Get right operand or memory counter
  • M₂ - Get left operand or memory base
  • M₃ - Get RAM
  • M₄ - Put A₀ (PSW)
  • M₅ - Put counter of Instruction Pointer (for HLT / CALL)
  • M₆ - Put result / base of Instruction Pointer (for HLT / CALL)
  • M₇ - Put to RAM (for MOV [RAM],reg)
It's very difficult for me, but it's work at this time.

In queue exist version of one-tick CPU, where Koy-Code decoded with a four Instruction Decoding blocks.
In this way the bytes «A1 AB 3D» readed as packed word «0xA1AB3D..» and each of four Decoders finds all parts for one tick. It's very difficult, but and very interesting too anyway! :D
More interest in plan, where that Koy-CPU used as core for emulation of i8080, where readed i8080-codes start the needed Koy-microprogramms.
At the one-tick Koy-CPU this is just tasty idea! 8-)

In the Instruction Set of Koy-CPU exist few strange combinations:
  • «nn+rr»: For example «33 AA»¹ can be dumb «XCHG A3,A3», but it's just stupid! In this way for «nn+rr» cases we need develop an exclusive instruction. As variant, that combination can signing a totally 396 privileged commands for internal Control Registers. It's very cool for serious task, like BIOS or OS-Kernel…
  • «mm+nn»: For example «12 34» at this time isn't support and the Verilog-model isn't tested for it. Totaly - 9801 combinations!
  • «ri+ri»: For example «A1 A2 A3» is work as «NOP», when select APR A₁, then A₂, then A₃. But the A₃ is actual only and A₁/A₂ is just dumb code. For this case I'm haven't any stable solves too…
  • «rt+rt»: For example «AB CD BC» is stupid «NOP» too, when selects operands «B,C» eventually, but «AB» and «CD» is just trash. And in this case I'm haven't any stabled ideas too…
  • More strange is «MOV [BiCi+n+R],R»² and it haven't solutions too…
¹: So, «33 AA» can work as «MOV Ai,S₃», where S₃ is State Register #3.
²: So, «A1 AA 23 A1» as «MOV [B₂C₂+3+A₁],A₁» can work as «MOV S₂,A₁», but index «3» is just wasted per very long code!

Important
The Koy-conception is very flexible in the side, where APRs capacity isn't have strict bitness. So, we can have no ALU, but FPU, where all operations are performed on floating point numbers, but machine byte-code of program is still styled by Koy-paradigm.

At this light the «Koyaanisqatsi» is not an esoteric CPU only, but original Script-Machine, like Java. That is, we mustn't to build concretic Koy-CPU implementation. And any Koy-CPU implementation is highly dependent on the goal.
So, for ByteBeat-Music we must to have the FPU with floats in APR, but the Instruction Pointer can be very tiny - 8-bits counter. And all dump-editor builded hardwary - on this switches. :lol:

All this Idea of CPU in the 2019 borned from that moments, where Human-friendly Byte-Code in Dump are on the first, and all other - are second side plan.

P.S.: Thank You for interesting! ;)


Sun Feb 14, 2021 8:29 pm
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
Wow - very ambitious to tackle the problem of parallel decoding of several possible overlapping instruction positions! But we know it can be done, of course, because it's now standard practice in the land of x86.

And yes, I see that the emphasis on readable machine code has left you with a bulky instruction stream. Always tradeoffs!


Tue Feb 16, 2021 11:47 am
Profile
User avatar

Joined: Sat Feb 13, 2021 12:22 pm
Posts: 10
Location: https://en.wikipedia.org/wiki/Tashkent
BigEd wrote:
Wow - very ambitious to tackle the problem of parallel decoding of several possible overlapping instruction positions!
Well, slightly different. :)
I thinking just about execution whole instruction without overlapping, where «ADD A1,B2» by «A1 AB 2A» is decoding as whole 32-bit stream from 0xA1AB2A. And actually, it's very easy: In the Logisim draft I got it for few hours.
Attachment:
File comment: One Tick Decoder
20210131_OneTicket.png
20210131_OneTicket.png [ 26.32 KiB | Viewed 2011 times ]

And in Verilog it really simple describe, if starting. But I'm haven't interesting in this time for that…
Quote:
But we know it can be done, of course, because it's now standard practice in the land of x86.
As we know, the i486 have RISC core. At the best luck and opportunity, if we can product something similar, then the i486 core we can simple reprogramming for digest this Koy-Code with biggest portions.
(if you know what I mean…)
Quote:
And yes, I see that the emphasis on readable machine code has left you with a bulky instruction stream. Always tradeoffs!
It's very interesting moment.
In the Koy-Code I can to encode a microcode for emulating the i8080 or z80. And I really considered this as homebrew z80 with Koy-Core.
But, we have the opposite too, when on z80 we can emulate Koy-Machine.

Just, Koyaanisqatsi in this light is very similar to Java-Machine, but with more obvious Machine Code.
I am attracted by the idea to have some cross-architecture for scripts, that can run in the HTML-emulation, in FPGA kit or in the ZX-Spectrum too!

P.S.: Idea is too raw, so I just can't build a full worked model even in the JavaScript: Too many dialects I'm watching.
I'm working with no targed goal, then my ideas like a plasticine with no form! :lol:


Tue Feb 16, 2021 5:01 pm
Profile WWW
User avatar

Joined: Sat Feb 13, 2021 12:22 pm
Posts: 10
Location: https://en.wikipedia.org/wiki/Tashkent
To reduce the vacuum of misunderstanding of programming, consider an example of the Console and DMA.
As I talking, the APR D₉ must to select the pages of in/out units.
Code:
D9=0xC0:Console Out (Display)
========
D0:Data Out as ASCII

D9=0xC1:Console In (Keyboard)
========
D1:Data In the ASCII

D9=0xCC:Clock Control (i8253)
========
D0:Channel #0A
D1:Channel #1A
D2:Channel #2A
D3:Control #A
D4:Channel #0B
D5:Channel #1B
D6:Channel #2B
D7:Control #B

D9=0xDC:DMA Control (i8257)
========
D0:Channel #0 address
D1:Channel #0 mode
D2:Channel #1 address
D3:Channel #1 mode
D4:Channel #2 address
D5:Channel #2 mode
D6:Channel #3 address
D7:Channel #3 mode
D8:Channels control

D9=0xDD:DMA Data stream
========
D0:Channel #0 write
D1:Channel #0 read
D2:Channel #1 write
D3:Channel #1 read
D4:Channel #2 write
D5:Channel #2 read
D6:Channel #3 write
D7:Channel #3 read
D8:- - -
In this environment we can programming like:
Code:
#define   CON_OUT      0xC0      // Console Out
#define   DMA_CTRL   0xDC      // DMA Control

void DMA_Set(void) {
   const address = 0x76D0;
   const length = 2340 - 1;
   D9 = DMA_CTRL;         // MOV D9,0xDC   ; DMA-Unit page
   D8 = DMA_AL;         // MOV D8,0x80   ; DMA-Setup begin
   D4 = LO(address);      // MOV D4,0xD0   ; Channel #2 low-address
   D4 = HI(address);      // MOV D4,0x76   ; Channel #2 high-address
   D5 = LO(length);      // MOV D5,0x23   ; Channel #2 low-length
   D5 = HI(length) | DMA_AL;   // MOV D5,0x49   ; Channel #2 high-length and mode
   D8 = DMA_AL | DMA_FW | DMA_EN2;   // MOV D8,0xA4   ; Start the DMA for channel #2
}

void DMA_Cycle(int length) {
   while(length --) {
      D9 = DMA_DATA;      // MOV D9,0xDD   ; DMA-Data page
      A1 = D5;      // MOV A1,D5   ; Read from Channel #2
      D9 = CON_OUT;      // MOV D9,0xC0   ; Console Output page
      D0 = A1;      // MOV D0,A1   ; Console Out
   }
}

void main(void) {
   DMA_Set();
   DMA_Cycle(78 * 30);      // Program level DMA-Cycle
   HALT;
}
Here we can see a lot of similarities with AVR controller programming for solving tiny tasks.
But it reaching even in the dump without the C…

P.S.: In this time I'm trying to develop a devices map for any emulation.


Thu Feb 18, 2021 4:00 pm
Profile WWW

Joined: Sun Dec 20, 2020 1:54 pm
Posts: 74
Yup, I like to play with a software simulator
Nice idea :D


Sat Feb 20, 2021 11:00 am
Profile

Joined: Sun Dec 20, 2020 1:54 pm
Posts: 74
Alikberov wrote:
As we know, the i486 have RISC core. At the best luck and opportunity, if we can product something similar, then the i486 core we can simple reprogramming for digest this Koy-Code with biggest portions.


For a couple of years there were around re-programmable prototypes with RISC-ish cores mounted on a ceramic package with the same pin-out used in 486 chips. It was appealing for hackers, but also probably an epic failure for the business and nobody never actually had the chance to play with them.

We are talking about things happened in the far 90s, now it's too late. Nowadays, I frankly prefer spending my time on RISC-V.


Sat Feb 20, 2021 11:12 am
Profile

Joined: Mon Oct 07, 2019 2:41 am
Posts: 585
I like to play with classic style instruction sets. 7 registers and a PC is more than ample for me and old ALTERA DE1 FPGA
kit. I can still emulate TTL with it so I can port tested firmware to real TTL hardware. I also am limiting my development
software to a C subset so can bootstrap with less hassle.
The KIT wants to push a ARM risc as developmet with some FPGA logic for I/O, if I wanted a RISC system
I would be well ARMED, but have to pay for the ARM licence.


Sat Feb 20, 2021 7:50 pm
Profile

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
Alikberov wrote:
To reduce the vacuum of misunderstanding of programming, consider an example...

Thanks for the worked example! Always useful, to see how a machine would be used (as opposed to, how it works.)


Sun Feb 21, 2021 8:51 am
Profile

Joined: Wed Nov 20, 2019 12:56 pm
Posts: 92
oldben wrote:
I like to play with classic style instruction sets. 7 registers and a PC is more than ample for me and old ALTERA DE1 FPGA
kit.


There's nothing wrong with the DE1, as long as its limited block RAM isn't a problem for your design. It's still as fast as any other entry-level Altera / Intel FPGA - they haven't changed all that much!


Sun Feb 21, 2021 9:57 am
Profile
User avatar

Joined: Sat Feb 13, 2021 12:22 pm
Posts: 10
Location: https://en.wikipedia.org/wiki/Tashkent
BigEd wrote:
Alikberov wrote:
To reduce the vacuum of misunderstanding of programming, consider an example...

Thanks for the worked example! Always useful, to see how a machine would be used (as opposed to, how it works.)
But it's just hollow example.

Now I try to show how it work…

If we have listing:
Code:
void DMA_Set(void) {
   const address = 0x76D0;
   const length = 2340 - 1;
   D9 = DMA_CTRL;                    // MOV D9,0xDC   ; DMA-Unit page
   D8 = DMA_AL;                      // MOV D8,0x80   ; DMA-Setup begin
   D4 = LO(address);                 // MOV D4,0xD0   ; Channel #2 low-address
   D4 = HI(address);                 // MOV D4,0x76   ; Channel #2 high-address
   D5 = LO(length);                  // MOV D5,0x23   ; Channel #2 low-length
   D5 = HI(length) | DMA_AL;         // MOV D5,0x49   ; Channel #2 high-length and mode
   D8 = DMA_AL | DMA_FW | DMA_EN2;   // MOV D8,0xA4   ; Start the DMA for channel #2
}

void DMA_Cycle(int length) {
   while(length --) {
      D9 = DMA_DATA;                 // MOV D9,0xDD   ; DMA-Data page
      A1 = D5;                       // MOV A1,D5     ; Read from Channel #2
      D9 = CON_OUT;                  // MOV D9,0xC0   ; Console Output page
      D0 = A1;                       // MOV D0,A1     ; Console Out
   }
}

void main(void) {
   DMA_Set();
   DMA_Cycle(78 * 30);               // Program level DMA-Cycle
   HALT;
}
That can compiled to:
Code:
0000    40 00|HLT 0x0040    ; BC0=0x0001, IP=0x0040
0002 CONSTANT|DB  0xDC,0x80,0xD0,0x76,0x23,0x49,0xA4
.... ........
0040 DD D9   |ARG D9,D9
0042    01 0F|MOV D9,[BC0+1]; BC0+1 == 0x0002 <0xDC>
0044 D8 02 0F|MOV D8,[BC0+2]; BC0+2 == 0x0003 <0x80>
0047 D4 03 0F|MOV D4,[BC0+3]; BC0+3 == 0x0004 <0xD0>
004A    04 0F|MOV D4,[BC0+4]; BC0+4 == 0x0005 <0x76>
004C D5 05 0F|MOV D5,[BC0+5]; BC0+5 == 0x0006 <0x23>
004F    06 0F|MOV D5,[BC0+6]; BC0+6 == 0x0007 <0x49>
0051 D8 07 0F|MOV D8,[BC0+7]; BC0+7 == 0x0008 <0xA4>
0054    08 DF|RET BC0+8     ; BC0=0x0055, IP=0x0009
0056 CONSTANT|DB  0x24,0x09 ; 78 * 30 == 0x0924
0058 CONSTANT|DB  0xDD,0xC0,0xFF
.... ........
0009 CC C1   |ARG C1,C1
000B    01 0F|MOV C1,[BC0+1]; BC0+1 == 0x0056 <0x24>
000D BB B1   |ARG B1,B1
000F    02 0F|MOV B1,[BC0+2]; BC0+2 == 0x0057 <0x09>
0011 AA A6   |ARG A6,A6
0013    03 0F|MOV A6,[BC0+3]; BC0+3 == 0x0058 <0xDD>
0015 A7 04 0F|MOV A7,[BC0+4]; BC0+4 == 0x0059 <0xC0>
0018 A8 05 0F|MOV A8,[BC0+5]; BC0+5 == 0x005A <0xFF>
001B    60 00|HLT 0x0060    ; BC0=0x001C, IP=0x0060
.... ........
0060 C0 CA 8A|ADD C0,A8     ; C0 += 0xFF; BC0=0x001B
0063 D9 DA 6F|MOV D9,A6     ; MOV D9,0xDD
0066 A1 AD 5F|MOV A1,D5
0069    DA 7F|MOV D9,A7     ; MOV D9,0xC0
006B D0    1F|MOV D0,A1
006D C1 CA 8A|ADD C1,A8     ; C1 += 0xFF
0070       DF|JNZ BC0       ; JNZ 0x001B
0071 B1 BA 8A|ADD B1,A8     ; B1 += 0xFF
0074       DF|JNZ BC0       ; JNZ 0x001B
0075    02 DE|JZ  BC0+2     ; JZ 0x001D
.... ........
001D AA AA AA|ARG AAA,AAA   ; NOP
0020    20 00|HLT 0x0020    ; HLT
Where dump looked like:
Code:
     .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
HINT:  BC0 +1 +2 +3 +4 +5 +6 +7 +8
0000 01 01<DC,80,D0,76,23,49,A4>CC C1 01 0F BB B1 02
0010 0F AA A6 03 0F A7 04 0F A8 05 0F 60 00 AA AA AA
0020 20 00 -- -- -- -- -- -- -- -- -- -- -- -- -- --
0030 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
0040 DD D9 01 0F D8 02 0F D4 03 0F 04 0F D5 05 0F 06
0050 0F D8 07 0F 08 DF<24,09,DD,C0,FF>-- -- -- -- --
0060 C0 CA 8A D9 DA 6F A1 AD 5F DA 7F D0 1F C1 CA 8A
0070 DF B1 BA 8A DF 02 DE -- -- -- -- -- -- -- -- --

It's looked very weird! Trully? :roll:
And branching is very weird! :o
And we must acquire the skill to read this and encode this, because we have no any C-translators! :mrgreen:

At this time I have almost finished debugging Koy-disassembler and Koy-emulator for USSR PC (i8080): It's trully working! :D
But I still have not good ideas about in/out D-environment and emulation is very limited: No demoscene, no colors, no music! :lol:

But It's amazing! It's working even on i8080!
Attachment:
File comment: Koyaanisqatsi emulator on i8080 - screenshot
Koy-8080.png
Koy-8080.png [ 9.59 KiB | Viewed 1943 times ]

And I can to write Koy-Code on JavaScript-Emulator, then run this Koy-Code in the i8080-emulator or Verilog-model.

Unfortunately, the LLVM is not support for Koy-Paradigm of branching. And I can't get any C-translator for Koyaanisqatsi.
It's bad!

P.S.: Thanks!


Sun Feb 21, 2021 11:30 am
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
That's significant progress! When you can, please share a link to your emulation solution.

I think a C compiler is a popular wish-list item, but often something which is just too far away. Have you considered BCPL?


Sun Feb 21, 2021 12:07 pm
Profile
User avatar

Joined: Sat Feb 13, 2021 12:22 pm
Posts: 10
Location: https://en.wikipedia.org/wiki/Tashkent
BigEd wrote:
That's significant progress!
Realy is an dilemma exist at here.

So, in the Soviet-PC has no CP/M-80, but whole RAM 0000…75FF is full accessible for user and 0000…6FFF under Koy-Code without any memory management.
But in the ZX-Spectrum addresses 0000…3FFF is under ROMs and 5C00…5CCF is under System Variables.

In this case we have tiny cross-space in RAM - 6000…6FFF (4 Kb), which can content the Koy-Code for emulation without any corrections and memory management on the ZX-Spectrum and Soviet-PC.

Then we can using this 4 Kb Koy-Code-Script for writing us Koy-Scenarios.

At here we can have an interesting moment, when Koy-Emulator can loaded at 7000…75FF on both machines without any corrections.
It can be is good demonstration for Koy-Conception with no memory management.

For example, we needing in the few functions only:
  • MOV D0,reg - if D8≠0 - print string by D8:D0, else - print ascii-character
  • MOV reg,D0 - get character under cursor
  • MOV D4,reg - Direct change cursor position 4t (At) X and Y: Y=D8, X=D4
  • MOV reg,D4 - get cursor position: D4=X, D8=Y
  • MOV D7,reg - Do Event - beep: D8 - duration, D7 - note
  • MOV D8,reg - optional, universal register
Environment Draft
BigEd wrote:
When you can, please share a link to your emulation solution.
Of course! :)
But I thinking, in first I must to rewrite all sources from Intel-syntax to Z80-syntax for published it.

So, personally for me, very useful using the Soviet-PC for debugging, where having i8275 - ASCII-Terminal controller with direct text area in memory: It very useful for debugging process.
And all my sources is at Intel-syntax.

But in ZX-Spectrum have graphical memory only and without libraries we can't type ASCII by direct memory writing.
We strictly wanted for character printing manager

I have hard dilemma too at here.
BigEd wrote:
I think a C compiler is a popular wish-list item, but often something which is just too far away. Have you considered BCPL?
If I can support the LLVM, any languages can using for translation?
Until the LLVM-level I not get, any High-Level Languages can't supports.


Sun Feb 21, 2021 5:00 pm
Profile WWW

Joined: Sun Dec 20, 2020 1:54 pm
Posts: 74
Well, first you have to write the machine-layer for the back-end :o

Although MIPS is *somehow* a mainstream processor (not like arm, but with more commercal interests than RISC-V) it hasn't yet got a decent and stable one for llvm; HPPA (HP-RISC) is not even close to being mainstream, and it's rather a niche things, however, although there it's still supported by Linux, and although there are several enthusiasts around the internet, it has never had a working machine layer for llvm/clang, and even the support for GCC is not exactly "brilliant" since there are several issues compiling 64bit-kernels. I know, because I actively support it, for my HPPA2 workstation.

From the above, I deduce (my pure speculation) that supporting llvm must not as easy as it sounds :shock:


Mon Feb 22, 2021 12:44 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 21 posts ]  Go to page 1, 2  Next

Who is online

Users browsing this forum: DataForSeoBot, SemrushBot and 12 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software