From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) by sourceware.org (Postfix) with ESMTPS id B8C9A383802F for ; Wed, 7 Jul 2021 20:33:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B8C9A383802F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x52c.google.com with SMTP id l24so5109951edr.11 for ; Wed, 07 Jul 2021 13:33:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cKrejO4Mc17Mj8wabvStxjF6HSOmmPKYJBQwNklFo+w=; b=GOta069vKm9ynp4iaLwb7ZURYghK3fCUfQH5YFMh0iXYH8DFrPbZ3N3vZTc07cddTZ 9za8jYAEIUGS7jzL0QQXfKscW03GPeuQSxz1aAtEDLIcpzL5HvMgcX2+OEBJdpiREarb hJ91gGgB8PKLF1kUuxMwQa5htolImW3M0zL3SPkwFCvjOZYBqwbLXtWsLQkaC9Fuislw t+SfSZlQWmSQ07YHwVnnacQRHou9jfsH5msUaQqBXhdrgpXbgSsBQOQIAMXvYHFnPBxc K6VxLD1X1qr/bDbhhrGF0Fk4qAfVgjKp561AmJxaQKxA02wfppyYAmGp83MsmGz+WloA NI3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cKrejO4Mc17Mj8wabvStxjF6HSOmmPKYJBQwNklFo+w=; b=o+6ekh0Ihw80Db1F4o2d/SPzLODdK0eEZxlTxNk/4XJqt2rRXWPnAfn90+Dv7KvhIh LNMxkDyHEJjRdaF3K4hXGvM7gC2bAjkaBSQvGlPd5gc/01hHAexXNTucFAo9zIdxmEkf KorMZj7wqpoEkwoe9h/GBYIDvzjvAVZ2RALUqwFz3oLDcg26dUR/gRuMmK86edWMtVrX Ztu4i78GsILiexrygURwTlz9LmsPsEPh5wMeTliABZ/iyY3n9LK6sx0EgWDJWsK3QHVm fCSihZMGw/rvaXr49dgLrHYjueWVugJ6tUsRwfU65zNhxcx2ZlUPLyLlb1Cvs38AfOTv 4dwg== X-Gm-Message-State: AOAM532uvnm+YwkrwrKFXCHoNFSj9vAzxPbYPw4TIaQIOUhxB7ckX38E EQtz23FgCb3OcZW6kiQMjSJ6eSZCZGte4XVnKHg= X-Google-Smtp-Source: ABdhPJzrV4tAkJn/yG3HGX+nAnj+tgQmwAhfQ7md/CZh4f2NiH2toCgC676U3+nhiG7SXSy+9IZk3/oESNIhCirVJYw= X-Received: by 2002:a05:6402:b07:: with SMTP id bm7mr26088769edb.345.1625689980836; Wed, 07 Jul 2021 13:33:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: ElijaxApps Date: Wed, 7 Jul 2021 22:32:49 +0200 Message-ID: Subject: Re: Help porting newlib to a new CPU architecture (sorta) To: Paul Koning Cc: Mike Frysinger , Newlib X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2021 20:33:04 -0000 Hi all, I started reading GCC Internals Book, chapter 16 & 17. I am deciding how exactly define insn statements at this very right moment. I am using pdp11 as a template. However, there are lots of things I don't really need, in this config spec. As far as I have understood, I can follow two paths: a) Define instructions as my pseudo assy, and use my own "assembler". b) Define instructions as Linux ASM and use GAS, GNU Assembler. At first I decided to apart A and use it as a Fallback if B fails. But I really think I am interested in both approaches. You see, I haven't coded any in real ASM and I just mimic'ed what it looks like. But I am a bit lost here, I feel like A is easier but it is not the "correct" way, but it can be done perhaps in a week or two... And let B for the long term, as I got practice and training with A. See the full instruction set for the moment (at the end of the document). What I would need for A is help writing the insn definition (for A this moment) I'll try to define the instructions BNF so you can help me to write insn definitions: *Offset*: [ 000000-ffffff ] [h] | *1) LDx *(Load REG from the BUS): [ LDA | LDB | LDC | LDD ] offset_to_load *2) STx *(Store REG in RAM): [ STA | STB | STC | STD ] offset_where_to_store *3) ADD,SUB*: [ ADD | SUB ] offset (to whatever already there is in A REG) *4) Jumps*: Always redirect to another direction in RAM, so they always are followed by an offset. *5) Branches*: Always redirect to another direction in RAM, this time a function beginning offset. They return a 24 bit address, and continue execution below where Branch was called. *6)* *DEC *(Read char and store in A REG) *Is all hardwired, is just the mnemonic - DEC - (cannot use another REG) *7) OUTx *(Output REG on LCD Screen) [ OUTA | OUTB | OUTC | OUTD ] *8) NOP, HLT *are just the mnemonic. MOV is not fully supported yet... "Spawning" a value into any register is not supported yet. You have to previously store the value you'll load into RAM. I have to encode ASCII table in the firmware, yet I not had time. So I need basically 2 TWO isns: *[ LDx | STx | Bx | Jx | ADD | SUB ] (24 bit hexadecimal, or variable name)[ DEC | OUTx | HLT | NOP ] - as is, just the mnemonic...* So that way I could continue the reading and go on. Thank You, Elijax Apps. Code tokenMeaningExamples ;; This is a comment. line will be ignored ;;This is a comment LDA Basic load A register. Always followed by a variable name or an memory address (up to 24 bit) LDA one LDA ff0010h LDB Same as LDA with B register LDC Same as LDA with C register LDD Same as LDA with D register STA Store contents of register A into the following address memory (also up to 24 bit) STA one STA ff0010h STB Same as STA with B register STC Same as STA with C register STD Same as STA with D register OUTA Echoes the value of register A to LCD Screen LDA one OUTA (prints value of variable "one") OUTB Same as OUTA with B register OUTC Same as OUTA with C register OUTD Same as OUTA with D register DEC Reads a byte from keyboard and stores in A register DEC STA readChar ADD Adds the value of the following address or variable to the contents of register A DEC ADD one SUB Substracts the value of the following address or variable to the contents of register A DEC ADD one JZ Jumps to the specified address or to specified address contained within a variable if Zero Flag =3D=3D 0 JZ addressToJumpTo, JZ 0000ffh JNZ Jumps to the specified address or to specified address contained within a variable if Zero Flag !=3D 0 JNZ addressToJumpTo, JNZ 0000ffh JC Jumps to the specified address or to specified address contained within a variable if Carry Flag =3D=3D 0 JC addressToJumpTo, JC 0000ffh JNC Jumps to the specified address or to specified address contained within a variable if Carry Flag !=3D 0 JNC addressToJumpTo, JNC 0000ffh J Jumps always J addressToJumpTo BZ Creates a branch (calls a function) if Zero Flag =3D=3D 0 BZ offsetOfFun= ction BNZ Creates a branch (calls a function) if Zero Flag !=3D 0 BNZ offsetOfFunction BC Creates a branch (calls a function) Carry Flag =3D=3D 0 BC offsetOfFunct= ion BNC Creates a branch (calls a function) if Carry Flag !=3D 0 BNC offsetOfFunction B Creates a branch (calls a function) always it is found B offsetOfFunction BX Returns a value contained in the following address BX returnValueAddress NOP No operation. Just reads the next operation NOP HLT Halts the computer HLT MOV Limited, not documented support for some MOV operations. SEE THE CODE!!! MOV A, C El mar, 6 jul 2021 a las 15:05, Paul Koning () escribi=C3=B3: > > > > On Jul 6, 2021, at 12:35 AM, Mike Frysinger wrote: > > > > On 06 Jul 2021 02:49, ElijaxApps wrote: > >> I designed a Logisim schematic of a full system, able to run programs = in > >> the simulation, as shown in this video: > >> > >> https://www.youtube.com/watch?v=3DUP6tO8x5I5A > >> > >> Is based on a SAP-1 (Simplest as Possible) basis, containing 4 GP > registers > >> (8 bit), stack for function operations (up to 256 depth levels of > >> recursivity), 24bit plain RAM component, and a simple ALU able to echo > >> strings and perform not floating point math. > >> > >> AFAIK, newlib is suitable for embedded devices, and I want to create t= he > >> full toolchain for C/C++ language at least. > > > > i don't know that these would work that well (or at all) on an 8-bit CP= U. > > you'd really want a 32-bit CPU nowadays as a minimum if you want to > support > > modern software. > > Consider the AVR toolchain, used in Arduino. Isn't that an 8-bit > machine? It certainly is small. > > paul > > >