looking around i didn't find any kind of basic re-implementation using hi level languages or, better, actual languages.

so i start a post dinner lecture of the c64 rom disasm, for example this http://myoperatingsystem.org/Commodore/Annotated_ROM_Listings.htm

i was trying to figure out how much time it will costs to rewrite, for example in javascript or native c, the original rom without changing it too much.

(yes, i know that already exist a "porting" (see http://www.pagetable.com/?p=48) but that's not what i mean.

ehm, not so easy!
some topics:
* lot of float math...slow
* lot of jsr to jump to jsr to 2-3 instruct code...again slow but also strange
* not so much kernel subs independent code: forth is very clean about it

i'm not saying that it's easy to write a 8k basic in '80 (in that period i also write lot of spaghetti code) but now i'm really curious about the commodore basic genesis/porting and if someone can give me more info for realizing a good porting without becoming crazy.

btw:
i'm doing a bit of work also in js 6502 code, that forum seems death, so if someone is interested...

Deeply-nested call-graphs (JSRs to JSRs to JSRs, etc) are a hallmark of writing software in a well-factored manner. You start out with basic primitives written in a stream of instructions, and you then can JSR to them as though they were a higher-level assembly instruction.

If you look at most high-level compiler output of the era, you'll notice that "subroutine-threaded code" like this was the norm, not the exception. Note that Forth is singularly famous for this style of code generation, although the technique technically predates Forth.

thank you for your reply, let me try to explain with some code.
...but anyway if basic was written with another high level language, i'm really curious about it!!!

here a piece of code, quite near the warm boot because it is used during the print of the banner using this core routine



look at jsr $AB47, that more or less is output one char.

it jump at:


this is good, a little reuse of and #$ff
but now the jsr $e10c (kernel rom)



and..


again: i dont wanna say that it's easy (better it was easy) to write code in 8k space, but now i can understand why a PRINT was so slow!

anyway i'd love to find out if there is a project for reimplement the original asm code in a new highlevel language, that's why i'm playing rom digging.

You would find the CHROUT routine at $FFD2 at all Commodore machines. This meant that various ML programs could run at various machines with different hardware. A large part of the $FF page was filled with these kind of vectors.
The indirect jump enabled you to redirect a vector to your own routines.

First CP/M and then IBM used these tricks as well. And it worked well. Until some programmers started to cut edges to speed up things. And then owners of some MS-DOS computers found out that some programs didn't run on their machines anymore: the now famous IBM incompatibility.

First after written the above I realise that I forgot an other, maybe more important argument. The JMP $FFD2 isn't slow at all; the interpretation of the Basic command PRINT is!

_________________

I think I understand now. The indirect jump for CHROUT is used to implement redirected I/O.

To produce a hard-copy listing of a BASIC program, for example, you'd use the CMD command to cause output to route to device 4 (e.g., OPEN 4,4:CMD 4:LIST:CLOSE 4). It's like file redirection logic in Unix or Windows.

I once wrote a quick-n-dirty hack that patched into these routines to provide a hierarchical directory system on which device drivers and filesystems could be mounted. Without having that extra layer of indirection, such a feature would have required I reprogrammed the entire KERNAL ROM, which is clearly not feasible for anyone else who might want to use the code.