Re: jeq instruction not documented in doc64/asm
Hi Dave,
> FYI, I see an instruction 'jeq' in used in src64/io.l, but I don't see
> it described in doc64/asm.
>
> Hm, for that matter, I don't see 'jne' or 'jgt' either. Maybe I
> shouldn't expect to find 'jeq'?
That's right: 'jeq' is just an alias for 'jz', as 'jlt' is one for 'jc'.
You can find the complete list in "src64/lib/asm.l":
(de *Transfers
call
jmp
jz jeq
jnz jne
js
jns
jsz
jnsz
jc jlt
jnc jge
jcz jle
jncz jgt )
(de *Conditions
(T jmp . jmp)
(z jz . jnz)
(nz jnz . jz)
(s js . jns)
(ns jns . js)
(sz jsz . jnsz)
(nsz jnsz . jsz)
(c jc . jnc)
(nc jnc . jc)
(cz jcz . jncz)
(ncz jncz . jcz)
(eq jz . jnz)
(ne jnz . jz)
(lt jc . jnc)
(le jcz . jncz)
(gt jncz . jcz)
(ge jnc . jc) )
> I guess ^@ is never valid inside a Transient Symbol?
>
> : "^@"
> Bad input '@'
Correct. Ctrl-@ is ASCII NULL, and is reserved as an end-of-name marker
in symbol names (just like in C).
> What does cmp do to the flags?
> cmp dst src # Compare 'dst' with 'src' [zsc]
* The zero-flag is set if 'dst' and 'src' are equal
* The sign-flag is set if the signed two-complement difference ('dst'
minus 'src') is negative
* The carry-flag is set if the unsigned difference ('dst' minus 'src')
results in carry out of the most significant bit
> Within the flag notation [---] in doc64/asm, What is the difference
> between . and -? I see that _ is clear.
'-' Flag is not modified
'.' Value of the flag is undefined
'_' Flag is cleared
For instructions where [...] isn't specified yet in the docs, we may
assume "don't care" for now.
♪♫ Alex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
jeq instruction not documented in doc64/asm
Hello. FYI, I see an instruction 'jeq' in used in src64/io.l, but I don't see it described in doc64/asm. Hm, for that matter, I don't see 'jne' or 'jgt' either. Maybe I shouldn't expect to find 'jeq'? I encountered 'jeq' in the 12th line of the definition of testEscA_F (which I pasted below my signature). I guess ^@ is never valid inside a Transient Symbol? : "^@" Bad input '@' ? Nope, it's not valid. Looks like we jumped to badInputErrB. So jeq is some kind of "jmp if ...". But it is different from these? jz adr# Jump to 'adr' if Zero [---] js adr# Jump to 'adr' if Sign [---] jc adr# Jump to 'adr' if Carry [---] What does cmp do to the flags? cmp dst src # Compare 'dst' with 'src' [zsc] Within the flag notation [---] in doc64/asm, What is the difference between . and -? I see that _ is clear. Cheers, thanks, --Dave (code 'testEscA_F 0) do null A # EOF? if s # Yes clrc # Return NO ret end cmp B (char "\^") # Caret? if eq # Yes call (Get_A) # Skip '^' cmp B (char "@") # At-mark? jeq badInputErrB # Yes cmp B (char "?") # Question-mark? if eq # Yes ld B 127 # DEL else and B 31 # Control-character end 10 setc # Return YES ret end cmp B (char "\\") # Backslash? jnz 10 # No call (Get_A) # Skip '\' cmp B 10 # Newline? jnz 10 # No do call (Get_A) # Skip white space cmp B 32 continue eq cmp B 9 until ne loop -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pilMCU progress (slowed)
Hi Alex,> > > as Jkob said, its a new 64bit CPU :) > > > > Some kind of derivative of this : http://software-lab.de/doc64/asm ? > > Bingo! Not a derivative, but a 1:1 implementation of that.Thanks! was going > to say the same thing :) Hi Kuba, > Cool, I use old school IMAP account with an actual quota (believe it or not > ;) )Cool!! ok let me check whats my easy option here :) > Some kind of derivative of this : http://software-lab.de/doc64/asm ? > > Cool design of the 64bit version that allows to create a completely custom > CPU or at the very least easy translation to pretty much any architectureAs > Alex pointed, it is the hardware implementation of the doc64/asm, indeed a > great design by Alex ;) > Technically both could be considered bare-metal environments running on > generic ARM cores.ah got it, then its the high level language here is just > considered as a C alternative here.. cool! hmm would it generate a more > optimized code than C too? that depends on the compiler right hmmm > I didn't really have time but I did give it a try and got it to work on my > STM32F4 - didn't take very long ;)yup! saw your post and it was interesting > to see the log, thanks for sharing! you mentioned on the slow performance hmm > let me understand the set up, you have a STM32F4 running miniPil inside and > you access the prompt thru UART correct? indeed fun ;) BR, geo On Wednesday, November 26, 2014 8:49 PM, Alexander Burger wrote: Hi Kuba, > > as Jkob said, its a new 64bit CPU :) > > Some kind of derivative of this : http://software-lab.de/doc64/asm ? Bingo! Not a derivative, but a 1:1 implementation of that. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pilMCU progress (slowed)
Hi Kuba, > > as Jkob said, its a new 64bit CPU :) > > Some kind of derivative of this : http://software-lab.de/doc64/asm ? Bingo! Not a derivative, but a 1:1 implementation of that. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pilMCU progress (slowed)
Hey, On Nov 26, 2014, at 12:09 AM, George Orais wrote: > Hi Kuba! > > I see that Jakob and Alex already covered most of your inquiry, but i'll just > answer you too ;) > > > > First of all, great progress with the pilMCU so far, I hope the EEPROM > > continues to work and you can move on to the next step. > > Thanks!! and yes, i utilized one push button so that every time i press it it > will increment the PC counter then it will fetch from EEPROM the stored > bytecode :) now i'm a bit busy with work coz of the coming CES :( but don't > worry, the I2C hurdle was done so EEPROM write should be already done, just > need to properly align the state machine inside ;) > > > > A small suggestion - please put big image files on some site (imgur etc) > > and attach - it would be easier, downloading large email file takes time (I > > don't use webmails like gmail). > > Oh! sorry about that and actually Jakob already called out on this, sorry > everyone i this will not happen again, either i change to smaller resolution > or use an external link as Kuba suggested Cool, I use old school IMAP account with an actual quota (believe it or not ;) ) > > > > Further, I have a couple questions on the implementation, > > you said you had an emulator running picolisp already - > > yes, we still got it ;) > > > > is this actually the whole picolisp converted somehow to a dedicated CPU > > running on FPGA, or is that an actual CPU emulated (say some kind of ARM), > > and picolisp compiled for that CPU ? > > as Jkob said, its a new 64bit CPU :) Some kind of derivative of this : http://software-lab.de/doc64/asm ? Cool design of the 64bit version that allows to create a completely custom CPU or at the very least easy translation to pretty much any architecture. > > > > I'm just trying to have a sense of what the pilMCU will become - will it be > > running on some kind of microcontroller, or will it actually run on a FPGA > > with a dedicated CPU, or maybe will it be some kind of ARM or MIPS core > > running on FPGA running the picolisp ? > > As of the moment, its the "will it actually run on a FPGA with a dedicated > CPU". This is just considered as prototype stage? And once we got this > running and able to get the funding we need? we will proceed of doing it to > ASIC? or even better but expensive, fabricate it to an actual standalone > microchip? this would be the ultimate goal, but does ASIC version has the > same purpose correct? but yes, the goal is to have a pilMCU chip on its own > development board in which would look like RPi, or TI BB or other > microcontroller kits these days that are capable of running Linux? once we > got this running Alex already started implementing an OS which is now stored > on an SD card :) > > > > Think for example of micropython or armpit-scheme - those are able to run > > on many microtrollers, I personally run them on a STM32F4 that's quite > > powerful (1MB flash, 200KB RAM) - pretty good for a mictrocontroller > > ah yes i think i read it somewhere? but hmm the difference is this still is > not considered as bare metal running of python or scheme, they still rely on > a small vm inside the microcontroller correct? or do you mean python and > scheme is used as programming syntax but then it is compiled to a STMicro > binary? micropython running on an MCU is simply compiled (C source with a little ASM) for ARM-cortex core with whatever additions required to initialize and use uControllers peripherals (just like minipicolisp that Alexander and me ported), I don't think there's any VM in between same applies to armpit-scheme, it's all in ARM assembly. Technically both could be considered bare-metal environments running on generic ARM cores. > > As mentioned by Alex, there is the miniPicolisp, im not sure on which MCU it > was run, something like Arduino maybe? Give it a try if you have time ;) I didn't really have time but I did give it a try and got it to work on my STM32F4 - didn't take very long ;) > > > BR, > geo > > > On Tuesday, November 25, 2014 10:14 PM, Alexander Burger > wrote: > > > Hi Kuba, > > in addition to what Jakob said: > > > Think for example of micropython or armpit-scheme - those are able to > > run on many microtrollers, I personally run them on a STM32F4 that's > > quite powerful (1MB flash, 200KB RAM) - pretty good for a > > mictrocontroller > > > I compiled miniPicoLisp here on an STM32F4-Discovery. Works almost > without changes, basically I removed only the command line parsing > stuff, and decreased the allocation size from 1 MB to 32 kB. > > As miniPicoLisp now can compile Lisp expressions to C code (see also > http://picolisp.com/wiki/?miniCodeROM), you can incrementally test Lisp > functions in the 196 kB of RAM and then move them to ROM > > ♪♫ Alex > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > > > -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?
Re: String syntax, or Transient Symbol syntax
On Wed, Nov 26, 2014 at 09:50:45AM +0100, Axel Svensson wrote: > I once wrote my own top-level REPL, if I remember correctly it was > compatible with picolisp syntax but also had the capability of adding > reader macros in the way OP desires. Let me know if you're interested, as > it might take me a while to dig it up. Or, you might take a look at the 'repl' function in the PicoLisp GUI in "lib/form.l", and modify that. It runs a REPL in a browser form. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: pilMCU on STM32F4-discovery
On Nov 26, 2014, at 4:10 PM, Alexander Burger wrote: > Hi Kuba, > >> ..and I just got to the same exact point, compiled minipicolisp for >> stm32f4-discovery, >> (same modifications, reduced allocation size, removed argc/argv etc). > > Great :) > > >> gdb session: >> ... >> GNU gdb (GNU Tools for ARM Embedded Processors) 7.6.0.20140731-cvs >> ... >> First impression - it's very slow, resembles a 1200bps terminal ;) but that >> was fun. > > Yes, I noticed that too. I also tried direct Telnet instead of GDB, but > it is the same. I think it has to do with how stdio is handled over the > USB link. The speed of PicoLisp itself is all right. > It is a debugging link afterall, meant rather for register access not a "regular" console interface. It's not very difficult to initialize proper STM32F4's UART and modify pil functions to direct its IO there - that should yield pretty decent console. I might do that someday when I find time. > ♪♫ Alex > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: String syntax, or Transient Symbol syntax
I once wrote my own top-level REPL, if I remember correctly it was compatible with picolisp syntax but also had the capability of adding reader macros in the way OP desires. Let me know if you're interested, as it might take me a while to dig it up. On Wed, Nov 26, 2014 at 8:05 AM, Alexander Burger wrote: > Hi Dave, > > > I am having some trouble working with Strings or Transient Symbols. > > (I'll call them strings for now.) > > ... > > "^(a+)\)" > > In picoLisp, I must enter that as: > > "\^(a+)\\)" > > That's right. This is the syntax of the PicoLisp reader. > > > > See, the escaping syntax is a pretty heavy burden for the types of > strings I work with... > > > > So, I considered using a reader macro. I imagined something like: > > > > (re-handler /^(a+)(.*)'.*(\)+)/ "nd here's some input! :") > > --> > > (re-handler "\^(a+)(.*)'.*(\\)+)" "nd here's some input! > :") > > A read macro won't help, because it is still based on 'read', the > PicoLisp reader synax. A read macro reads an expression, evaluates it, > and returns the result to the reader. > > > > ..Then I discovered that we don't have a defmacro. (I've read previous > > discussion about macros and I accept Alex's stance.) > > A macro won't help either, because it also processes the data *after* > they are read by the Lisp reader. And though you can do everything a > macro would do in PicoLisp with a normal function, it also operates on > s-expressions and not on the input stream. > > > > Any advice for implementing some sort of special case for /strings/, > > which would be just like "strings" but with different escape mechanics? > > On the *application* level, you can do everything you like, using > low-level I/O functions like 'char' and 'line'. > > I think the problem is that you want to change the *language* level, and > the reader is the core of the language (read/eval/print). > > > > I see src64/io.l contains (code 'readA_E) which handles reading > > "strings". But I don't understand this assembly code. > > Yes, that's the right place to change the language :) > > > The normal REPL (i.e. the 'load' function) doesn't operate on raw input > data. > > What you could do is write you own top-level REPL, using e.g. 'line' and > 'eval' directly. Another possibility is using 'pipe' and perhaps > external tools to process the input stream. In any case you need to get > hold of the data and process them *before* they are seen by the reader. > > ♪♫ Alex > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
